JP2000284995A - データ処理装置及び記録媒体 - Google Patents

データ処理装置及び記録媒体

Info

Publication number
JP2000284995A
JP2000284995A JP11087457A JP8745799A JP2000284995A JP 2000284995 A JP2000284995 A JP 2000284995A JP 11087457 A JP11087457 A JP 11087457A JP 8745799 A JP8745799 A JP 8745799A JP 2000284995 A JP2000284995 A JP 2000284995A
Authority
JP
Japan
Prior art keywords
log
metadata
transaction
meta
volume
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
JP11087457A
Other languages
English (en)
Other versions
JP3763992B2 (ja
Inventor
Michihiko Koseki
道彦 小関
Mamoru Yokoyama
衛 横山
Masashi Washimi
昌司 鷲見
Satoru Yamaguchi
悟 山口
Sadayoshi Taniwaki
貞善 谷脇
Seishiro Hamanaka
征志郎 浜中
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.)
Fujitsu Ltd
Original Assignee
Fujitsu 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 Fujitsu Ltd filed Critical Fujitsu Ltd
Priority to JP08745799A priority Critical patent/JP3763992B2/ja
Priority to US09/501,568 priority patent/US6732124B1/en
Publication of JP2000284995A publication Critical patent/JP2000284995A/ja
Application granted granted Critical
Publication of JP3763992B2 publication Critical patent/JP3763992B2/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/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1435—Saving, restoring, recovering or retrying at system level using file system or storage system metadata
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0866—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches for peripheral storage systems, e.g. disk cache
    • G06F12/0868—Data transfer between cache memory and other subsystems, e.g. storage devices or host systems
    • 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/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1471—Saving, restoring, recovering or retrying involving logging of persistent data for recovery
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/08—Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0804—Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches with main memory updating
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/46—Caching storage objects of specific type in disk cache
    • G06F2212/466—Metadata, control data
    • 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/99941—Database schema or data structure
    • Y10S707/99943—Generating database or data structure, e.g. via user interface
    • 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

【発明の詳細な説明】
【０００１】
【発明の属する技術分野】本発明はファイルシステムの
修正機能を有するデータ処理装置及び記録媒体に関し、
特にログを用いてファイルシステムの不整合の修正を行
うデータ処理装置及び記録媒体に関する。
【０００２】
【従来の技術】コンピュータシステムを運用している
と、何らかの理由によりシステムがダウンする場合があ
る。突然のシステムダウンが発生すると、ファイルシス
テムの不整合が生じる。そこで、システムダウン後のブ
ート時には、従来であればファイルシステム全体を走査
し、その矛盾点の検出を行う。矛盾点が発見されたら、
場合に応じた変更をファイルシステムに加えることによ
って、ファイルシステムの整合性を回復していた。とこ
ろが、ファイルシステム全体を走査するには多くの時間
が必要であり、結果としてシステムダウン後の復旧の遅
れを招いていた。
【０００３】そこで近代のＵＮＩＸオペレーティングシ
ステム（ＯＳ）のような多くのコンピュータＯＳのファ
イルシステムでは、ファイルシステムオペレーションに
おいてファイルシステムに保存されているデータが更新
される度に、その更新情報をログ（ジャーナル）として
採取している。ファイルシステムオペレーション時に更
新情報のログ採取を行っておくことにより、システムダ
ウン後のブート時のファイルシステム整合性チェックの
フェーズでは、残されたログを順次走査し、対応する領
域へアップデートすることによって、ファイルシステム
の整合性が保証される。その結果、システムのダウン時
間が短縮される。
【０００４】
【発明が解決しようとする課題】しかし、ログ機構を導
入することにより、次に挙げる問題が生じていた。 （１）第１の問題点 ファイルを管理するメタデータ（二次記憶装置に格納さ
れたファイルを管理するためのデータ）は、ファイルシ
ステムオペレーション時に二次記憶装置からメモリへ読
み込まれ、メモリ内において操作される。その後、所定
のタイミングで二次記憶装置へとその更新内容が反映さ
れる。ログ機構の導入時には、その二次記憶装置への反
映前に更新内容をログ専用の二次記憶装置へと記録する
必要がある。
【０００５】しかし、大規模ファイルシステムに対応す
るために、複数の二次記憶装置がメタデータに割り当て
られ、異なる二次記憶装置に割り当てられたメタデータ
を１つのファイルシステムオペレーションが操作する場
合がある。このファイルシステムオペレーションのログ
を採取する際に、メモリ内のメタデータだけをログとし
て記録していたのでは、残されたログからメタデータ毎
に異なる二次記憶装置を検索するのに時間を消費し、ロ
グ機構導入による最大のメリットである、ファイルシス
テム復元の時間短縮に悪い影響を与える。
【０００６】（２）第２の問題点 同様にファイルシステム復元の時間短縮に悪い影響を与
える要因として、有限なサイズしかないログ専用の二次
記憶装置全体をファイルシステム復元時に探索すること
が考えられる。
【０００７】ログ機構の導入はファイルシステムオペレ
ーションを細分化したトランザクションの完了を常に保
証しつつ動作するため、ログ機構を導入した多くのファ
イルシステムはトランザクションにシーケンス番号を与
え、ファイルシステム復元時にはシーケンス番号をもと
に最古のトランザクションを同定する。そして、最古の
トランザクションからログリプレイと呼ばれるログを用
いたファイルシステム復元操作を開始する。
【０００８】ここで、有限サイズのログ専用の二次記憶
装置内には、ファイルシステムの整合性を復元するため
に欠かせないログが確かに存在する可能性があるが、有
限なサイズを有効利用するためにログ専用の二次記憶装
置は過去のログを上書きしてサイクリックに利用しなけ
ればならない。このような処理を行うには、ある程度以
上古いログが必ず不必要となっていることが前提とな
る。従って、多くのログの内容は既に不必要となってい
る。すなわち、ログ専用の二次記憶装置全体を探索ある
いは反映するのは非効率的である。
【０００９】（３）第３の問題点 最古のトランザクションを特定するためのシーケンス番
号は単調増加であることが要求され、運用途中にオーバ
ーフローによってゼロに戻されてしまうことは許されな
い。これを回避するために、ファイルシステム復元作業
終了時、またはオーバーフロー直前にログ専用の二次記
憶装置全体をゼロクリアし、再度シーケンス番号ゼロか
ら順にトランザクションを処理するのが一般的である。
しかし、ログ専用の二次記憶装置をゼロクリアするため
には多くの時間が必要となる。少なくともシステムの運
用を一時停止する必要があり、サーバ装置などによるサ
ービスの提供を停止せざるを得なくなってしまう。
【００１０】以上の（１）〜（３）の課題はファイルシ
ステム復元時の問題であるが、ログ機構を導入すること
は通常の運用時にも問題を引き起こす可能性を持ってい
る。ログ機構は、メモリ上にログをスプールする手法
や、ログ専用の二次記憶装置として用いられるディスク
の特性を考慮したシーケンシャルアクセスなど、高速化
のための条件は整えられているが、ログの採取の仕方を
熟考しなければ、ログ採取に伴う性能劣化は非常に大き
いものとなりうる。
【００１１】（４）第４の問題点 単一のトランザクション内で、同一データを複数回更新
することは度々あるが、その都度、その同一データに対
するログを採取したのではメモリが不足し、二次記憶装
置へのＩ／Ｏ量が増加する。
【００１２】（５）第５の問題点 ログ機構の導入はトランザクションの順序性を保証し、
終了したトランザクションのログを順に採取することを
要求するために、あるトランザクションが操作したログ
対象データを他のトランザクションが操作することが一
般的に不可能な状況となりうる。ここで、個々のファイ
ルの内容を対象とするトランザクションについては、フ
ァイル単位に排他制御を行うことによって、複数のトラ
ンザクションが並列実行することは比較的容易である。
しかしながら、個々のファイルによらないもの、特に領
域の割り当て情報を操作する場合には、並列実行がきわ
めて難しくなる。
【００１３】領域の獲得・解放処理が並列に動作する場
合を考えると、それぞれが獲得、解放のログを採取す
る。同一の管理情報（ここでは、ビットマップを考え
る）によって管理される領域の獲得・解放処理であった
場合には、同一の管理情報が、解放された状態、獲得さ
れた状態でログに記録されることになる。
【００１４】ファイルシステムの復元処理を行わなけれ
ばならないようなシステムダウンが発生するタイミング
によっては、このように別トランザクションの更新情報
を含むログの採取方式では様々な問題が生じる。
【００１５】Ａというトランザクションが解放処理、Ｂ
というトランザクションが獲得処理を行う場合を考え
る。ここで、トランザクションＡの解放処理はトランザ
クションＢの獲得処理よりも先に行われ、かつ、トラン
ザクションＡはトランザクションＢよりも後に終わる場
合を例に挙げる。
【００１６】このとき、トランザクションＡが開放した
領域をトランザクションＢが獲得してしまう場合が考え
られる。トランザクションＢが先に終了することから、
残されたログには、まず獲得処理が記録され、次に解放
処理が記録される。
【００１７】上記の場合のトランザクションＢのログだ
けが記録されており、それを復元に用いた場合には、本
来行われたはずである解放処理の記録が残されていない
ことから、該当領域が二重に獲得された状態となってし
まう。トランザクションＡのログまで記録されており、
復元に用いられると、トランザクションＢが利用してい
る領域がトランザクションＡの解放処理のログによって
解放されている状態となってしまう。いずれも本来の状
態とは異なっており、避けなければならない。しかしな
がら、これを回避するために並列実行を制限すること
は、マルチタスクを実現したＯＳ上のファイルシステム
の速度性能の低下に与える影響が非常に大きい。
【００１８】（６）第６の問題点 既に述べたようにログ機構の第一の目的としてファイル
システムを復元するために費やす時間の短縮が挙げられ
るが、そのためにトランザクションの独立性を疎かにし
たり、中途半端な状態での整合性回復によりあたかも正
常に動作しているかのように振る舞うファイルシステム
が多く見受けられる。
【００１９】従来のメタデータ管理方式のように、ログ
を記録するためのメモリ空間をファイルシステム全体で
１つのキャッシュメモリを共有していたのではトランザ
クション毎の独立性を保つのが難しく、他のトランザク
ションによる更新情報が１つのトランザクションのログ
として記録されてしまう可能性が高い。特にファイルに
対する排他で制御しきれない割り当て管理情報について
は前述の通りである。
【００２０】（７）第７の問題点 トランザクション毎に必要とするログのサイズが異なる
ことから、複数のログバッファとしてログを記録するた
めのメモリをトランザクション毎に割り当て、管理する
場合に、全てのメモリサイズが同一である必要はない。
例えば、ファイルの参照時刻を更新するだけのトランザ
クションが残すログのサイズは大変小さく、巨大なデー
タ書き込み要求のトランザクションは必然的にそれだけ
大きいログサイズとなる。
【００２１】（８）第８の問題点 トランザクション毎に残すログサイズの違いを考慮し
て、限られたメモリ空間の有効利用を試みても、キャッ
シュメモリサイズは残されるログサイズに比較して、や
はり小さい。
【００２２】（９）第９の問題点 「第８の問題点」の解決策として、１つのトランザクシ
ョンを分割し、中途の状態のログを出力することが考え
られる。しかし、一般にファイルを管理するメタデータ
は、トランザクションが中途の状態ではやはり中途の状
態であり、そのままログに記録したところで、そのログ
を用いて復元されるファイルシステムは中途の状態にし
かなり得ない。これではオペレーションのセマンティク
スを保証した復元とはなり得ない。
【００２３】（１０）第１０の問題点 「第９の問題点」で示した中途の状態でのトランザクシ
ョンの中断はファイルシステムにとって危険な状態とい
える。ログ機構の導入は、採取したログをログボリュー
ムに反映するまでは該当メタデータもキャッシュメモリ
から追い出せないことを意味する。ログがキャッシュメ
モリに入りきらないほど巨大となっているときには、メ
タデータを管理するキャッシュメモリの利用率も高くな
っていることが考えられる。ログを出力するまでメタデ
ータをキャッシュメモリから追い出せないため、このよ
うな状態で多くのトランザクションが並列実行される
と、メモリ枯渇によるハングアップ状態に陥ることも考
えられる。
【００２４】（１１）第１１の問題点 第１０の問題点と同様の資源枯渇はログ記録用の二次記
憶装置についても言える。キャッシュメモリに比較すれ
ば巨大な二次記憶装置についても、メタデータ記録用の
二次記憶装置へのＩ／Ｏを削減するために、多くのログ
を有効なログとして残しておけば、それは利用可能な領
域の減少を引き起こす。その際に多数のトランザクショ
ンの並列実行を許すことはメタデータキャッシュ枯渇、
ログキャッシュ枯渇、ログ記録用二次記憶装置枯渇、な
どを誘発する可能性がある。
【００２５】本発明はこのような点に鑑みてなされたも
のであり、ファイルシステム修復処理の効率化を図った
データ処理装置を提供することを目的とする。
【００２６】
【課題を解決するための手段】本発明では上記課題を解
決するための第１の発明として、ログを用いてファイル
システムの不整合の修正を行うデータ処理装置におい
て、ファイルを管理するメタデータを記憶するための二
次記憶装置である複数のメタボリュームと、メタデータ
の更新結果であるログを記憶するための二次記憶装置で
あるログボリュームと、メタデータを記憶するために主
記憶装置内に設けられたメタキャッシュと、メタデータ
の内容が変更される際に、対象となるメタデータを前記
メタキャッシュへと読み込むメタデータ読み込み手段
と、前記メタキャッシュ内に読み込まれたメタデータの
内容を更新するトランザクションと、前記メタキャッシ
ュに読み込まれたメタデータが格納されていたメタボリ
ュームの識別情報を管理するメタデータ管理手段と、前
記メタキャッシュ内で変更されたメタデータの内容をロ
グとして採取するとともに、採取したメタデータが格納
されていたメタボリュームの識別情報を採取するログ採
取手段と、前記ログ採取手段が採取した情報を保持する
ログバッファと、前記ログバッファが保持する情報を、
適宜前記ログボリュームに格納するログ書き込み手段
と、を有することを特徴とするデータ処理装置が提供さ
れる。
【００２７】このようなデータ処理装置によれば、トラ
ンザクションがメタデータの更新をする際には、まず、
メタデータ読み込み手段によりメタボリューム内の必要
なメタデータがメタキャッシュに読み込まれる。その
際、読み込んだメタデータがどのメタボリュームから読
み込まれたものであるのかが、メタデータ管理手段によ
って管理される。ここで、トランザクションがメタデー
タの内容を更新すると、ログ採取手段によって更新後の
メタデータがログとして採取される。この際、メタデー
タが格納されていたメタボリュームの識別情報をも採取
する。採取した情報は、ログバッファに保持される。そ
して、ログ書き込み手段により、ログバッファ内の情報
がログボリュームに書き込まれる。
【００２８】また、上記課題を解決する第２の発明とし
て、ログを用いてファイルシステムの不整合の修正を行
うデータ処理装置において、ファイルを管理するメタデ
ータを記憶するための二次記憶装置であるメタボリュー
ムと、メタデータの更新結果であるログを記憶するため
の二次記憶装置であるログボリュームと、メタデータを
記憶するために主記憶装置内に設けられたメタキャッシ
ュと、メタデータの内容が変更される際に、対象となる
メタデータを前記メタキャッシュへと読み込むメタデー
タ読み込み手段と、前記メタキャッシュ内に読み込まれ
たメタデータの内容を更新するトランザクションと、前
記メタキャッシュ内で変更されたメタデータの内容をロ
グとして採取するログ採取手段と、前記ログ採取手段が
採取した情報を保持するログバッファと、前記ログボリ
ューム内の領域を定期的に循環するようにして、前記ロ
グバッファが保持する情報を前記ログボリュームに格納
するログ書き込み手段と、前記メタキャッシュ内のメタ
データをメタボリューム内に格納するメタデータ書き込
み手段と、前記メタデータ書き込み手段による書き込み
動作を監視しており、変更内容が前記メタボリュームに
反映されていないメタデータに対応する前記ログボリュ
ーム内のログを、有効なログとして指定する有効範囲監
視手段と、ファイルシステム復元要求を受け取ると、前
記ログボリュームに格納されたログの中で、前記有効範
囲監視手段により有効なログとして指定されているログ
のみを用いて、前記メタボリューム内のメタデータの不
整合を修正するファイルシステム復元手段と、を有する
ことを特徴とするデータ処理装置が提供される。
【００２９】このようなデータ処理装置によれば、トラ
ンザクションがメタデータの更新をする際には、まず、
メタデータ読み込み手段によりメタボリューム内の必要
なメタデータがメタキャッシュに読み込まれる。ここ
で、トランザクションがメタデータの内容を更新する
と、ログ採取手段によって更新後のメタデータがログと
して採取される。採取した情報は、ログバッファに保持
される。そして、ログ書き込み手段により、ログバッフ
ァ内の情報がログボリュームに書き込まれる。その後、
メタデータ書き込み手段により、メタキャッシュ内のメ
タデータがメタボリューム内に格納される。その書き込
み動作は、有効範囲監視手段で監視されており、変更内
容がメタボリュームに反映されていないメタデータに対
応するログボリューム内のログが、有効なログとして指
定される。そして、ファイルシステム復元要求が出され
ると、ファイルシステム復元手段により、ログボリュー
ムに格納されたログの中で、有効範囲監視手段により有
効なログとして指定されているログのみを用いて、メタ
ボリューム内のメタデータの不整合が修正される。
【００３０】また、上記課題を解決する第３の発明とし
て、ログを用いてファイルシステムの不整合の修正を行
うデータ処理装置において、ファイルを管理するメタデ
ータを記憶するための二次記憶装置であるメタボリュー
ムと、メタデータの更新結果であるログを記憶するため
の二次記憶装置であるログボリュームと、メタデータを
記憶するために主記憶装置内に設けられたメタキャッシ
ュと、メタデータの内容が変更される際に、対象となる
メタデータを前記メタキャッシュへと読み込むメタデー
タ読み込み手段と、前記メタキャッシュ内に読み込まれ
たメタデータの内容を更新するトランザクションと、前
記メタキャッシュ内で変更されたメタデータの内容をロ
グとして採取するログ採取手段と、前記ログ採取手段が
採取した情報を保持するログバッファと、前記ログバッ
ファが保持する情報を前記ログボリュームに格納するロ
グ書き込み手段と、前記ログボリュームに格納されたロ
グを用いて前記メタボリューム内のメタデータの不整合
を修正するファイルシステム復元手段と、前記ファイル
システム復元手段が前記メタボリューム内のメタデータ
の不整合を修正した時に用いられたログの最後のシーケ
ンス番号を記憶する初期シーケンス番号記憶手段と、
前記ログ書き込み手段がログの書き込みを行う際に、シ
ーケンス番号を昇順で採番し、採番したシーケンス番号
を書き込むべきログに付与しており、前記ファイルシス
テム復元手段が前記メタボリューム内のメタデータの不
整合を修正した直後には、前記初期シーケンス番号記憶
手段に格納されたシーケンス番号を基準として採番する
シーケンス番号採番手段と、を有することを特徴とする
データ処理装置が提供される。
【００３１】このようなデータ処理装置によれば、トラ
ンザクションがメタデータの更新をする際には、まず、
メタデータ読み込み手段によりメタボリューム内の必要
なメタデータがメタキャッシュに読み込まれる。ここ
で、トランザクションがメタデータの内容を更新する
と、ログ採取手段によって更新後のメタデータがログと
して採取される。採取した情報は、ログバッファに保持
される。そして、ログ書き込み手段により、ログバッフ
ァ内の情報がログボリュームに書き込まれる。その際、
シーケンス番号採番手段により、シーケンス番号が昇順
で採番され、書き込むべきログに付与される。ファイル
システムに不整合が発生すると、ファイルシステム復元
手段により、ログボリュームに残されたログを用いてメ
タデータの不整合が修正される。このとき、修正に用い
られた最後のログのシーケンス番号が初期シーケンス番
号記憶手段に記憶される。その後、ログ書き込み手段に
よりログバッファ内の情報がログボリュームに書き込ま
れると、シーケンス番号採番手段により、初期シーケン
ス番号記憶手段に格納されたシーケンス番号を基準とし
てシーケンス番号が採番され、書き込むべきログに付与
される。
【００３２】また、上記課題を解決する第４の発明とし
て、ログを用いてファイルシステムの不整合の修正を行
うデータ処理装置において、ファイルを管理するメタデ
ータを記憶するための二次記憶装置であるメタボリュー
ムと、メタデータを記憶するために主記憶装置内に設け
られたメタキャッシュと、メタデータの内容が変更され
る際に、対象となるメタデータを前記メタキャッシュへ
と読み込むメタデータ読み込み手段と、前記メタキャッ
シュ内に読み込まれたメタデータの内容を更新するトラ
ンザクションと、前記トランザクションの種別を判断
し、メタデータの更新を複数回行う可能性のあるトラン
ザクションの場合には、前記メタキャッシュ内で変更さ
れたメタデータの最終形態のみをログとして採取するロ
グ採取手段と、を有することを特徴とするデータ処理装
置が提供される。
【００３３】このようなデータ処理装置によれば、トラ
ンザクションがメタデータの更新をする際には、まず、
メタデータ読み込み手段によりメタボリューム内の必要
なメタデータがメタキャッシュに読み込まれる。ここ
で、トランザクションがメタデータの内容を更新する。
すると、ログ採取手段により、トランザクションの種別
が判断され、メタデータの更新を複数回行う可能性のあ
るトランザクションの場合には、メタキャッシュ内で変
更されたメタデータの最終形態のみがログとして採取さ
れる。
【００３４】また、上記課題を解決する第５の発明とし
て、ログを用いてファイルシステムの不整合の修正を行
うデータ処理装置において、メタデータに対する割り当
てを管理するための割り当て管理情報を複数の領域に分
割して保持する割り当て管理情報保持手段と、前記割り
当て管理情報保持手段内の割り当て管理情報の一部領域
の複製を生成し、獲得操作用管理情報とするとともに、
前記獲得操作用管理情報内に未獲得のメタデータがなく
なると、割り当て管理情報の別の領域の複製を前記獲得
操作用管理情報とする獲得操作用管理情報生成手段と、
メタデータの獲得及び解放要求を出力するトランザクシ
ョンと、前記トランザクションによりメタデータの獲得
要求が出された場合には、前記獲得操作用管理情報の中
の未獲得のメタデータを獲得し、獲得したメタデータを
獲得済みとするように前記獲得操作用管理情報と前記割
り当て管理情報との内容を変更するメタデータ獲得手段
と、前記トランザクションによりメタデータの解放要求
が出された場合には、指定されたメタデータが未獲得の
状態となるように、前記割り当て管理情報の内容を変更
するメタデータ解放手段と、を有することを特徴とする
データ処理装置が提供される。
【００３５】このようなデータ処理装置によれば、獲得
操作用管理情報生成手段により、割り当て管理情報の一
部領域の複製が生成され、獲得操作用管理情報とされ
る。トランザクションにより獲得要求があると、メタデ
ータ獲得手段により、獲得操作用管理情報内の未獲得の
メタデータが獲得される。すると、獲得操作用管理情報
と割り当て管理情報との内容が更新される。また、トラ
ンザクションよりメタデータの解放要求があると、メタ
データ解放手段により該当するメタデータの解放処理が
行われる。この際、割り当て管理情報の内容のみが更新
される。ここで、獲得操作用管理情報内に未獲得のメタ
データがなくなると、割り当て管理情報内の別の領域の
複製が獲得操作用管理情報とされる。
【００３６】また、上記課題を解決する第６の発明とし
て、ログを用いてファイルシステムの不整合の修正を行
うデータ処理装置において、メタデータに対する割り当
てを管理するための割り当て管理情報を保持する割り当
て管理情報保持手段と、メタデータの獲得及び解放要求
を出力するトランザクションと、前記トランザクション
によりメタデータの獲得要求が出された場合には、前記
割り当て管理情報保の中の未獲得のメタデータを獲得
し、獲得したメタデータを獲得済みとするように前記割
り当て管理情報の内容を変更するメタデータ獲得手段
と、前記トランザクションによりメタデータの解放要求
が出された場合には、指定されたメタデータ未獲得の状
態となるように、前記割り当て管理情報の内容を変更す
るメタデータ解放手段と、前記割り当て管理情報内の前
記メタデータ獲得手段及び前記メタデータ解放手段によ
って変更された部分の情報をログとして採取するログ採
取手段と、を有することを特徴とするデータ処理装置が
提供される。
【００３７】このようなデータ処理装置によれば、トラ
ンザクションからメタデータの獲得要求が出されると、
メタデータ獲得手段によって未獲得のメタデータの１つ
が割り当て管理情報内から獲得され、そのメタデータが
獲得済みの状態とされる。また、トランザクションから
メタデータの解放要求が出されると、メタデータ解放手
段によって該当するメタデータが未獲得の状態に変更さ
れる。そして、ログ採取手段により、割り当て管理情報
内のメタデータ獲得手段及びメタデータ解放手段によっ
て変更された部分の情報がログとして採取される。
【００３８】また、上記課題を解決する第７の発明とし
て、ログを用いてファイルシステムの不整合の修正を行
うデータ処理装置において、ファイルを管理するメタデ
ータを記憶するための二次記憶装置であるメタボリュー
ムと、メタデータを記憶するために主記憶装置内に設け
られたメタキャッシュと、メタデータの内容が変更され
る際に、対象となるメタデータを前記メタキャッシュへ
と読み込むメタデータ読み込み手段と、前記メタキャッ
シュ内に読み込まれたメタデータの内容を更新する複数
のトランザクションと、 ログをトランザクション毎に
保持する、サイズの異なる複数のログバッファと、前記
メタキャッシュ内で変更されたメタデータの内容をログ
として採取し、前記トランザクション毎に分けて前記ロ
グバッファに格納するログ採取手段と、を有することを
特徴とするデータ処理装置が提供される。
【００３９】このようなデータ処理装置によれば、トラ
ンザクションがメタデータの更新をする際には、まず、
メタデータ読み込み手段によりメタボリューム内の必要
なメタデータがメタキャッシュに読み込まれる。ここ
で、トランザクションがメタデータの内容を更新する。
すると、ログ採取手段により、メタキャッシュ内で変更
されたメタデータがログとして採取され、トランザクシ
ョン毎のログバッファに保持される。
【００４０】また、上記課題を解決する第８の発明とし
て、ログを用いてファイルシステムの不整合の修正を行
うデータ処理装置において、ファイルを管理するメタデ
ータを記憶するための二次記憶装置であるメタボリュー
ムと、メタデータの更新結果であるログを記憶するため
の二次記憶装置であるログボリュームと、メタデータを
記憶するために主記憶装置内に設けられたメタキャッシ
ュと、メタデータの内容が変更される際に、対象となる
メタデータを前記メタキャッシュへと読み込むメタデー
タ読み込み手段と、前記メタキャッシュ内に読み込まれ
たメタデータの内容を更新するトランザクションと、ロ
グをトランザクション毎に保持するログバッファと、前
記メタキャッシュ内で変更されたメタデータの内容をロ
グとして採取し、前記ログバッファに格納するログ採取
手段と、前記トランザクションが終了した場合に前記ロ
グバッファの内容を前記ログボリュームに書き込むとと
もに、前記トランザクションによるログが前記ログバッ
ファ内に格納しきれない場合には、前記ログバッファ内
のデータを完結したログに加工し、中間ログとして前記
ログボリューム内に格納するログ書き込み手段と、を有
することを特徴とするデータ処理装置が提供される。
【００４１】このようなデータ処理装置によれば、トラ
ンザクションがメタデータの更新をする際には、まず、
メタデータ読み込み手段によりメタボリューム内の必要
なメタデータがメタキャッシュに読み込まれる。ここ
で、トランザクションがメタデータの内容を更新する
と、ログ採取手段によって更新後のメタデータがログと
して採取される。採取した情報は、ログバッファに保持
される。そして、ログバッファに格納しきれなくなる
か、トランザクションが終了すると、ログ書き込み手段
により、ログバッファ内の情報がログボリュームに書き
込まれる。ログバッファに格納しきれなくなった場合に
は、ログバッファの内容を完結したログに加工され、中
間ログとしてログボリュームに格納される。
【００４２】また、上記課題を解決する第９の発明とし
て、ログを用いてファイルシステムの不整合の修正を行
うデータ処理装置において、ファイルを管理するメタデ
ータを記憶するための二次記憶装置であるメタボリュー
ムと、メタデータの更新結果であるログを記憶するため
の二次記憶装置であるログボリュームと、メタデータを
記憶するために主記憶装置内に設けられたメタキャッシ
ュと、メタデータの内容が変更される際に、対象となる
メタデータを前記メタキャッシュへと読み込むメタデー
タ読み込み手段と、前記メタキャッシュ内に読み込まれ
たメタデータの内容を更新する、複数同時実行可能なト
ランザクションと、前記トランザクションからの開始要
求を受け付けると、ログ採取に関するシステムの動作状
況を判断し、前記トランザクションの受け入れ許否を判
断するトランザクション受け入れ判断手段と、前記メタ
キャッシュ内で変更されたメタデータの内容をログとし
て採取するログ採取手段と、前記ログ採取手段が採取し
た情報を保持するログバッファと、前記ログバッファが
保持する情報を、適宜前記ログボリュームに格納するロ
グ書き込み手段と、を有することを特徴とするデータ処
理装置が提供される。
【００４３】このようなデータ処理装置によれば、トラ
ンザクションから開始要求が出されると、トランザクシ
ョン受け入れ制限手段が受け入れの許否を判断する。そ
の後、メタデータ書き込み手段によるメタデータの書き
込みが進み、有効なログの割合が減少したら、その時点
でトランザクションの開始要求を許可する。
【００４４】
【発明の実施の形態】以下、本発明の実施の形態を図面
を参照して説明する。図１は、第１の発明の原理構成図
である。この第１の発明は、複数の二次記憶装置がメタ
データに割り当てられている場合におけるファイルシス
テム不整合修復時間の短縮を図るものである。
【００４５】このデータ処理装置には、二次記憶装置と
してメタボリューム１ａ，１ｂ，１ｃとログボリューム
２とが設けられている。各メタボリューム１ａ，１ｂ，
１ｃには、ファイルを管理するためのメタデータが記憶
されている。また、ログボリューム２には、メタデータ
の更新結果であるログが記憶されている。また、主記憶
装置内にはメタキャッシュ３が設けられている。メタキ
ャッシュ３は、メタデータを記憶するための主記憶装置
内の記憶領域である。メタデータ読み込み手段４は、メ
タデータの内容が変更される際に、対象となるメタデー
タをメタキャッシュ３へと読み込む。メタデータ管理手
段５は、メタキャッシュ３に読み込まれたメタデータが
格納されていたメタボリューム１ａ，１ｂ，１ｃの識別
情報を管理する。トランザクション６は、メタキャッシ
ュ３内に読み込まれたメタデータの内容を更新する。ロ
グ採取手段７は、メタキャッシュ３内で変更されたメタ
データの内容をログとして採取するとともに、採取した
メタデータが格納されていたメタボリューム１ａ，１
ｂ，１ｃの識別情報を採取する。ログバッファ８は、ロ
グ採取手段７が採取した情報を保持する。ログ書き込み
手段９は、ログバッファ８が保持する情報を、適宜ログ
ボリューム２に格納する。
【００４６】このようなデータ処理装置よれば、トラン
ザクション６がメタデータの更新をする際には、まず、
メタデータ読み込み手段４によりメタボリューム１ａ〜
１ｃ内の必要なメタデータがメタキャッシュ３に読み込
まれる。その際、読み込んだメタデータがどのメタボリ
ュームから読み込まれたものであるのかが、メタデータ
管理手段５によって管理される。ここで、トランザクシ
ョン６がメタデータの内容を更新すると、ログ採取手段
７によって更新後のメタデータがログとして採取され
る。この際、メタデータが格納されていたメタボリュー
ム１ａ〜１ｃの識別情報をも採取する。採取した情報
は、ログバッファ８に保持される。そして、ログ書き込
み手段９により、ログバッファ８内の情報がログボリュ
ーム２に書き込まれる。
【００４７】これにより、ログボリューム２に保持され
たログがどのメタボリューム１ａ〜１ｃのメタデータに
関するログであるのかを管理することができる。その結
果、複数のメタボリューム１ａ〜１ｃにメタデータが格
納されていても、ファイルシステムの不整合を修正する
ことが可能となる。
【００４８】図２は、第２の発明の原理構成図である。
第２の発明は、ログの有効範囲を監視することで、ファ
イルシステム復元時の効率化を図ったものである。第２
の発明は、以下のような要素で構成される。
【００４９】メタボリューム１１は、ファイルを管理す
るメタデータを記憶するための二次記憶装置である。ロ
グボリューム１２は、メタデータの更新結果であるログ
を記憶するための二次記憶装置である。メタキャッシュ
１３は、メタデータを記憶するために主記憶装置内に設
けられた記憶領域である。メタデータ読み込み手段１４
は、メタデータの内容が変更される際に、対象となるメ
タデータをメタキャッシュ１３へと読み込む。トランザ
クション１５は、メタキャッシュ１３内に読み込まれた
メタデータの内容を更新する。ログ採取手段１６は、メ
タキャッシュ１３内で変更されたメタデータの内容をロ
グとして採取するとともに、採取したメタデータが格納
されていたメタボリュームの識別情報を採取する。ログ
バッファ１７は、ログ採取手段１６が採取した情報を保
持する。ログ書き込み手段１８は、ログボリューム１２
内の領域を定期的に循環するようにして、ログバッファ
１７が保持する情報をログボリューム１２に格納する。
メタデータ書き込み手段１９は、メタキャッシュ１３内
のメタデータをメタボリューム１１内に格納する。有効
範囲監視手段２０は、メタデータ書き込み手段１９によ
る書き込み動作を監視しており、変更内容がメタボリュ
ーム１１に反映されていないメタデータに対応するログ
ボリューム１２内のログを、有効なログとして指定す
る。ファイルシステム復元手段２１は、ファイルシステ
ム復元要求を受け取ると、ログボリューム１２に格納さ
れたログの中で、有効範囲監視手段２０により有効なロ
グとして指定されているログのみを用いて、メタボリュ
ーム１１内のメタデータの不整合を修正する。なお、有
効範囲監視手段２０による有効なログの指定方法として
は、例えば、有効範囲を示す情報を不揮発性の記録媒体
（ログボリューム１２等）に記録することができる。こ
の場合、ファイルシステム復元手段２１は、有効範囲が
記録された不揮発性の記録媒体内の情報を読みとること
で、有効なログと指定されているログを認識できる。
【００５０】このようなデータ処理装置によれば、トラ
ンザクション１５がメタデータの更新をする際には、ま
ず、メタデータ読み込み手段１４によりメタボリューム
１１内の必要なメタデータがメタキャッシュ１３に読み
込まれる。ここで、トランザクション１５がメタデータ
の内容を更新すると、ログ採取手段１６によって更新後
のメタデータがログとして採取される。採取した情報
は、ログバッファ１７に保持される。そして、ログ書き
込み手段１８により、ログバッファ１７内の情報がログ
ボリューム１２に書き込まれる。その後、メタデータ書
き込み手段１９により、メタキャッシュ１３内のメタデ
ータがメタボリューム１１内に格納される。その書き込
み動作は、有効範囲監視手段２０で監視されており、変
更内容がメタボリューム１１に反映されていないメタデ
ータに対応するログボリューム１２内のログが、有効な
ログとして指定される。そして、ファイルシステム復元
要求が出されると、ファイルシステム復元手段２１によ
り、ログボリューム１２に格納されたログの中で、有効
範囲監視手段２０により有効なログとして指定されてい
るログのみを用いて、メタボリューム１１内のメタデー
タの不整合が修正される。
【００５１】これにより、ファイルシステムを復元する
際には、ログボリューム１２内の有効なログのみを用い
て効率よく復元処理を行うことが可能となる。図３は、
第３の発明の原理構成図である。第３の発明は、ログに
付加するシーケンス番号のデータサイズを十分大きなも
のとし、シーケンス番号を常に昇順で使い続けることが
できる（ゼロクリアが不要となる）ようにしたものであ
る。第３の実施の形態は、以下のような要素で構成され
る。
【００５２】メタボリューム３１は、ファイルを管理す
るメタデータを記憶するための二次記憶装置である。ロ
グボリューム３２は、メタデータの更新結果であるログ
を記憶するための二次記憶装置である。メタキャッシュ
３３は、メタデータを記憶するために主記憶装置内に設
けられた記憶領域である。メタデータ読み込み手段３４
は、メタデータの内容が変更される際に、対象となるメ
タデータをメタキャッシュ３３へと読み込む。トランザ
クション３５は、メタキャッシュ３３内に読み込まれた
メタデータの内容を更新する。ログ採取手段３６は、メ
タキャッシュ３３内で変更されたメタデータの内容をロ
グとして採取する。ログバッファ３７は、ログ採取手段
３６が採取した情報を保持する。ログ書き込み手段３８
は、ログバッファが保持する情報を前記ログボリューム
に格納する。ファイルシステム復元手段３９は、ログボ
リューム３２に格納されたログを用いてメタボリューム
３１内のメタデータの不整合を修正する。初期シーケン
ス番号記憶手段３０ａは、ファイルシステム復元手段３
９がメタボリューム３１内のメタデータの不整合を修正
した時に用いられたログの最後のシーケンス番号を記憶
する。シーケンス番号採番手段３０ｂは、ログ書き込み
手段３８がログの書き込みを行う際に、シーケンス番号
を昇順で採番し、採番したシーケンス番号を書き込むべ
きログに付与しており、ファイルシステム復元手段３９
がメタボリューム３１内のメタデータの不整合を修正し
た直後には、初期シーケンス番号記憶手段３０ａに格納
されたシーケンス番号を基準として採番する。
【００５３】このようなデータ処理装置によれば、トラ
ンザクション３５がメタデータの更新をする際には、ま
ず、メタデータ読み込み手段３４によりメタボリューム
３１内の必要なメタデータがメタキャッシュ３３に読み
込まれる。ここで、トランザクション３５がメタデータ
の内容を更新すると、ログ採取手段３６によって更新後
のメタデータがログとして採取される。採取した情報
は、ログバッファ３７に保持される。そして、ログ書き
込み手段３８により、ログバッファ３７内の情報がログ
ボリューム３２に書き込まれる。その際、シーケンス番
号採番手段３０ｂによりシーケンス番号が昇順で採番さ
れ、書き込むべきログに付与される。また、ファイルシ
ステム復元手段３９により、ログボリューム３２に格納
されたログを用いてメタボリューム３１内のメタデータ
の不整合が修正されると、修正した時に用いられたログ
の最後のシーケンス番号が初期シーケンス番号記憶手段
３０ａに記憶される。その後、ログ書き込み手段３８に
より、ログバッファ３７内の情報がログボリューム３２
に書き込まれると、シーケンス番号採番手段３０ｂによ
り、初期シーケンス番号採番手段３０ａに記憶されたシ
ーケンス番号を基準としてシーケンス番号が昇順で採番
され、書き込むべきログに付与される。
【００５４】これにより、既にファイルシステムの復元
に用いたログと、ファイルシステム復元後に介したトラ
ンザクションのログとのシーケンス番号が重ならないこ
とを保証することができる。その結果、システムが使用
可能な期間中にログボリュームをゼロクリアする必要が
なくなり、ゼロクリアに伴う処理の遅延を避けることが
できる。
【００５５】図４は、第４の発明の原理構成図である。
第４の発明は、同じメタデータに対して複数回更新処理
が行われる場合に、最終形態のメタデータのみをログと
して採取するものである。第４の発明は、以下のような
要素で構成される。
【００５６】メタボリューム４１は、ファイルを管理す
るメタデータを記憶するための二次記憶装置である。メ
タキャッシュ４２は、メタデータを記憶するために主記
憶装置内に設けられた記憶領域である。メタデータ読み
込み手段４３は、メタデータの内容が変更される際に、
対象となるメタデータをメタキャッシュ４２へと読み込
む。トランザクション４４は、メタキャッシュ４２内に
読み込まれたメタデータの内容を更新する。ログ採取手
段４５は、トランザクション４４の種別を判断し、メタ
データの更新を複数回行う可能性のあるトランザクショ
ンの場合には、メタキャッシュ４２内で変更されたメタ
データの最終形態のみをログとして採取する。ログバッ
ファ４６は、ログ採取手段４５が採取した情報を保持す
る。
【００５７】このようなデータ処理装置によれば、トラ
ンザクション４４がメタデータの更新をする際には、ま
ず、メタデータ読み込み手段４３によりメタボリューム
４１内の必要なメタデータがメタキャッシュ４２に読み
込まれる。ここで、トランザクション４４がメタデータ
の内容を更新する。すると、ログ採取手段４５により、
トランザクション４４の種別が判断され、メタデータの
更新を複数回行う可能性のあるメタデータ属性を予測す
る。予測されたメタデータ属性において、同一メタデー
タが何度も更新される可能性がある場合には、その属性
のメタデータがメタキャッシュ４２内で変更された時点
ではログ採取を行わず、トランザクション４４が終了し
た時点で、最終形態のメタデータをログとして採取す
る。採取した情報は、ログバッファ４６に保持される。
【００５８】これにより、複数回更新されたメタデータ
のログを更新処理の度に採取することがなくなり、メモ
リの効率化を図ることができるともに、ログを書き出す
ときのＩ／Ｏの量も減らすことができる。
【００５９】図５は、第５の発明の原理構成図である。
第５の発明は、メタデータ割り当て管理情報の一部の複
製を生成し、複製として生成した情報内からのみメタデ
ータの獲得を可能とし、解放する際には、割り当て管理
情報においてのみ解放された旨の情報の更新を行うこと
で、解放直後に別のトランザクションに獲得されるのを
防止したものである。第５の発明は、以下のような要素
で構成される。
【００６０】割り当て管理情報保持手段５１は、メタデ
ータに対する割り当てを管理するための割り当て管理情
報５１ａを複数の領域に分割して保持する。獲得操作用
管理情報生成手段５２は、割り当て管理情報保持手段５
１内の割り当て管理情報の一部領域の複製を生成し、獲
得操作用管理情報５１ｂとする。また、獲得操作用管理
情報５１ｂ内に未獲得のメタデータがなくなると、割り
当て管理情報の別の領域の複製を獲得操作用管理情報５
１ｂとする。トランザクション５３は、メタデータの獲
得及び解放要求を出力する。メタデータ獲得手段５４
は、トランザクション５３によりメタデータの獲得要求
が出された場合には、獲得操作用管理情報５１ｂの中の
未獲得のメタデータを獲得し、獲得したメタデータを獲
得済みとするように獲得操作用管理情報５１ｂと割り当
て管理情報５１ａとの内容を変更する。メタデータ解放
手段５５は、トランザクション５３によりメタデータの
解放要求が出された場合には、指定されたメタデータが
未獲得の状態となるように、割り当て管理情報の内容を
変更する。
【００６１】このようなデータ処理装置によれば、獲得
操作用管理情報生成手段５２により、割り当て管理情報
５１ａの一部領域の複製が生成され、獲得操作用管理情
報５１ｂとされる。トランザクション５３により獲得要
求があると、メタデータ獲得手段５４により、獲得操作
用管理情報５１ｂ内の未獲得のメタデータが獲得され
る。すると、獲得操作用管理情報５１ｂと割り当て管理
情報５１ａとの内容が更新される。また、トランザクシ
ョン５３よりメタデータの解放要求があると、メタデー
タ解放手段５５により該当するメタデータの解放処理が
行われる。この際、割り当て管理情報５１ａの内容のみ
が更新される。ここで、獲得操作用管理情報５１ｂ内に
未獲得のメタデータがなくなると、割り当て管理情報５
１ａ内の別の領域の複製が獲得操作用管理情報５１ｂと
される。
【００６２】これにより、解放された旨の情報が獲得操
作用管理情報５１ｂに反映されないため、解放直後のメ
タデータが他のトランザクションに獲得されることがな
くなる。その結果、解放処理を行ったトランザクション
の終了前にシステムがダウンしても、少なくとも解放前
の状態のまま保全されることが保証される。
【００６３】図６は、第６の発明の原理構成図である。
第６の発明は、トランザクション単位に、獲得や解放に
関する情報をログとして記録することで、必要なメモリ
容量の削減を図るとともに、平行動作するトランザクシ
ョンのログに起因して割り当て管理情報に不正な状態が
発生することを防ぐものである。第６の発明は、以下の
ような要素で構成される。
【００６４】割り当て管理情報保持手段６１は、メタデ
ータに対する割り当てを管理するための割り当て管理情
報を保持する。トランザクション６２は、メタデータの
獲得及び解放要求を出力する。メタデータ獲得手段６３
は、トランザクション６２によりメタデータの獲得要求
が出された場合には、獲得操作用管理情報の中の未獲得
のメタデータを獲得し、獲得したメタデータを獲得済み
とするように割り当て管理情報６１ａの内容を変更す
る。メタデータ解放手段６４は、トランザクション６２
によりメタデータの解放要求が出された場合には、指定
されたメタデータ未獲得の状態となるように、割り当て
管理情報６１ａの内容を変更する。ログ採取手段６５
は、割り当て管理情報内のメタデータ獲得手段６３及び
メタデータ解放手段６４によって変更された部分の情報
をログとして採取する。ログバッファ６６は、ログ採取
手段６５が採取したログを保持する。
【００６５】このようなデータ処理装置によれば、トラ
ンザクション６２からメタデータの獲得要求が出される
と、メタデータ獲得手段６３によって未獲得のメタデー
タの１つが割り当て管理情報６１ａ内から獲得され、そ
のメタデータが獲得済みの状態とされる。また、トラン
ザクション６２からメタデータの解放要求が出される
と、メタデータ解放手段６４によって該当するメタデー
タが未獲得の状態に変更される。そして、ログ採取手段
６５により、割り当て管理情報６１ａ内のメタデータ獲
得手段６３及びメタデータ解放手段６４によって変更さ
れた部分の情報がログとして採取され、ログバッファ６
６に保持される。
【００６６】このように、獲得、解放のログを採取する
際に、トランザクションが獲得や解放を行ったという情
報のみをログとして格納することで、メモリ等の領域を
効率よく利用することができるとともに、他トランザク
ションによる獲得や解放処理の情報がログに含まれない
ことによって、割り当て管理情報が不正な状態となるこ
とを防ぐことができる。
【００６７】図７は、第７の発明の原理構成図である。
第７の発明は、ログバッファを複数設けることにより、
トランザクションの独立性をいっそう高めたものであ
る。第７の発明の構成要素は以下の通りである。
【００６８】メタボリューム７１は、ファイルを管理す
るメタデータを記憶するための二次記憶装置である。メ
タキャッシュ７２は、メタデータを記憶するために主記
憶装置内に設けられた記憶領域である。メタデータ読み
込み手段７３は、メタデータの内容が変更される際に、
対象となるメタデータをメタキャッシュ７２へと読み込
む。複数のトランザクション７４ａ〜７４ｃは、メタキ
ャッシュ７２内に読み込まれたメタデータの内容を更新
する。複数のログバッファ７５ａ〜７５ｅは、ログをト
ランザクション毎に保持する。各ログバッファ７５ａ〜
７５ｅのサイズは一定ではなく、大きなサイズや小さな
サイズが存在する。ログ採取手段７６は、メタキャッシ
ュ７２内で変更されたメタデータの内容をログとして採
取し、前記トランザクション毎に分けて適したサイズの
ログバッファ７５ａ〜７５ｅに格納する。例えば、最初
にログを格納する場合には、トランザクションの内容に
よって予想される処理に適した大きさのログバッファに
格納し、格納対象となるログバッファの記憶容量が不足
してきたら、より大きな記憶容量のログバッファへログ
を移し替え、以後、より大きな記憶容量のログバッファ
をログの格納対象とする。
【００６９】このようなデータ処理装置によれば、トラ
ンザクション７４ａ〜７４ｃがメタデータの更新をする
際には、まず、メタデータ読み込み手段７３によりメタ
ボリューム７１内の必要なメタデータがメタキャッシュ
７２に読み込まれる。ここで、トランザクション７４ａ
〜７４ｃがメタデータの内容を更新する。すると、ログ
採取手段７６により、メタキャッシュ７２内で変更され
たメタデータがログとして採取され、適したサイズのロ
グバッファ７５ａ〜７５ｅに保持される。
【００７０】このように、複数のログバッファに分け、
トランザクション毎に１つのログバッファを使用するよ
うにしたことで、トランザクションの独立性を保つこと
ができる。しかも、複数のサイズのログバッファを用意
し、トランザクション毎に適したサイズのログバッファ
を使用することにより、メモリを効率的に利用できる。
【００７１】図８は、第８の発明の原理構成図である。
第８の発明は、あるトランザクションのログがログバッ
ファに入りきらない場合に、中間ログとしてログバッフ
ァの内容を書き出すものである。第８の発明の構成は以
下の通りである。
【００７２】メタボリューム８１は、ファイルを管理す
るメタデータを記憶するための二次記憶装置である。ロ
グボリューム８２は、メタデータの更新結果であるログ
を記憶するための二次記憶装置である。メタキャッシュ
８３は、メタデータを記憶するために主記憶装置内に設
けられた記憶領域である。メタデータ読み込み手段８４
は、メタデータの内容が変更される際に、対象となるメ
タデータをメタキャッシュ８３へと読み込む。トランザ
クション８５は、メタキャッシュ８３内に読み込まれた
メタデータの内容を更新する。ログバッファ８６は、ロ
グをトランザクション毎に保持する。ログ採取手段８７
は、メタキャッシュ８３内で変更されたメタデータの内
容をログとして採取し、ログバッファ８６に格納する。
ログ書き込み手段８８は、トランザクション８５が終了
した場合にログバッファ８６の内容をログボリューム８
２に書き込むとともに、トランザクション８５によるロ
グがログバッファ８６内に格納しきれない場合には、ロ
グバッファ８６内のデータを完結したログに加工し、中
間ログとしてログボリューム８２内に格納する。なお、
中間ログを生成する際には、中間ログに対してトランザ
クションを実行するのに必要とされたパラメタに関する
情報を付加する。ファイルシステム復元手段８９は、フ
ァイルシステム復元要求を受け取ると、ログボリューム
８２に格納されたログを用いて、メタボリューム８１内
のメタデータの不整合を修正する。このとき、中間ログ
を発見すると、中間ログに含まれたパラメタを用いてト
ランザクションを再実行させる。
【００７３】このようなデータ処理装置によれば、トラ
ンザクション８５がメタデータの更新をする際には、ま
ず、メタデータ読み込み手段８４によりメタボリューム
８１内の必要なメタデータがメタキャッシュ８３に読み
込まれる。ここで、トランザクション８５がメタデータ
の内容を更新すると、ログ採取手段８７によって更新後
のメタデータがログとして採取される。採取した情報
は、ログバッファ８６に保持される。そして、ログバッ
ファ８６に格納しきれなくなるか、トランザクション８
５が終了すると、ログ書き込み手段８８により、ログバ
ッファ８６内の情報がログボリューム８２に書き込まれ
る。ログバッファ８６に格納しきれなくなった場合に
は、ログバッファ８６の内容を完結したログに加工し、
中間ログとしてログボリューム８２に格納する。そし
て、ファイルシステム復元要求が出されると、ファイル
システム復元手段８９により、ログボリューム８２に格
納されたログを用いて、メタボリューム８１内のメタデ
ータの不整合が修正されるとともに、中間ログまで採取
した段階で停止しているトランザクションが再実行され
る。
【００７４】これにより、メタデータの更新を大量に行
うトランザクションの実行中にシステムがダウンした場
合には、途中の状態まで戻すことができるとともに、ト
ランザクションが再実行されることで、トランザクショ
ンの実行後の状態へ遷移させることができる。
【００７５】図９は、第９の発明の原理構成図である。
トランザクションの受け入れを一定の条件によって制限
することで、メモリ枯渇等を防止するものである。第９
の発明の構成は以下の通りである。
【００７６】メタボリューム９１は、ファイルを管理す
るメタデータを記憶するための二次記憶装置である。ロ
グボリューム９２は、メタデータの更新結果であるログ
を記憶するための二次記憶装置である。メタキャッシュ
９４は、メタデータを記憶するために主記憶装置内に設
けられた記憶領域である。メタデータ読み込み手段９３
は、メタデータの内容が変更される際に、対象となるメ
タデータをメタキャッシュ９４へと読み込む。互いの同
時実行可能な複数のトランザクション９０ｂ〜９０ｄ
は、メタキャッシュ９４内に読み込まれたメタデータの
内容を更新する。トランザクション受け入れ制限手段９
０ａは、トランザクション９０ｂ〜９０ｄからの開始要
求を受け付けると、ログ採取に関するシステムの動作状
況に基づいて、トランザクション９０ｂ〜９０ｄの受け
入れ許否を判断する。受け入れ判断基準としては、例え
ばログボリューム内の有効なログが占める割合を用い
る。すなわち、有効範囲監視手段９９によって有効なロ
グとされたログがログボリューム中に占める割合が一定
値以上である間は、トランザクション９０ｂ〜９０ｄの
受け入れを拒絶する。
【００７７】ログ採取手段９６は、メタキャッシュ９４
内で変更されたメタデータの内容をログとして採取す
る。ログバッファ９５は、ログ採取手段９６が採取した
情報を保持する。ログ書き込み手段９７は、ログバッフ
ァ９５が保持する情報を、適宜ログボリューム９２に格
納する。メタデータ書き込み手段９８は、メタキャッシ
ュ９４内のメタデータをメタボリューム９１内に格納す
る。有効範囲監視手段９９は、メタデータ書き込み手段
９８による書き込み動作を監視しており、変更内容が前
記メタボリュームに反映されていないメタデータに対応
するログボリューム９２内のログを、有効なログとして
指定する。
【００７８】このようなデータ処理装置によれば、トラ
ンザクション９０ｂ〜９０ｄから開始要求が出される
と、トランザクション受け入れ制限手段９０ａが受け入
れの許否を判断する。例えば、有効範囲監視手段９９に
より有効であると指定されたログのログボリューム９２
内に示す割合が一定以上の場合には、それ以上ログが発
生しないように、トランザクションの受け入れを拒絶す
る。その後、メタデータ書き込み手段９８によるメタデ
ータの書き込みが進み、有効なログの割合が減少した
ら、その時点でトランザクションの開始要求を許可す
る。
【００７９】これにより、ログボリュームの空き容量の
減少に伴うハングアップなどの障害の発生を防止するこ
とができる。次に、本発明の実施の形態を具体的に説明
する。
【００８０】図１０は、本発明を適用するデータ処理装
置のハードウェア構成図である。データ処理システム
は、ＣＰＵ(Central Processing Unit)２１１を中心に
構成されている。ＣＰＵ２１１は、バス２１７を介して
他の機器を制御するとともに、様々なデータ処理を行
う。バス２１７には、メモリ２１２、入力機器インタフ
ェース２１３、表示制御回路２１４、ＨＤＤ(Hard Disk
Drive)インタフェース２１５、及びネットワークイン
タフェース２１６が接続されている。
【００８１】メモリ２１２は、ＣＰＵ２１１が実行すべ
きプログラムや、プログラムの実行に必要な各種データ
を一時的に保持する。入力機器インタフェース２１３
は、入力機器としてキーボード２２１とマウス２２２が
接続されており、これらの入力機器からの入力内容をＣ
ＰＵ２１１に伝える。
【００８２】表示制御回路２１４は、表示装置２２３が
接続されており、ＣＰＵ２１１から送られてきた画像デ
ータを表示装置２２３で表示可能な画像情報に変換し、
表示装置２２３の画面に表示させる。
【００８３】ＨＤＤインタフェース２１５は、複数のＨ
ＤＤ２３１〜２３３が接続されており、ＣＰＵ２１１か
ら送られてきたデータをＨＤＤ２３１〜２３３に格納す
るとともに、ＣＰＵ２１１からの要求に応じてＨＤＤ２
３１〜２３３内のデータを読み取り、ＣＰＵ２１１に転
送する。
【００８４】ネットワークインタフェース２１６は、Ｌ
ＡＮ(Local Area Network)に接続されており、ＬＡＮを
介してデータ通信を行う。すなわち、ＣＰＵ２１１から
送られたデータをＬＡＮに接続された他のコンピュータ
に転送するとともに、他のコンピュータからＬＡＮを介
して送られてきたデータをＣＰＵ２１１に転送する。
【００８５】ＨＤＤ２３１〜２３３には、各種ファイル
や、そのファイルを管理するためのメタデータ及びログ
が格納されている。このような構成のシステムにおい
て、ＣＰＵ２１１がＨＤＤ２３１〜２３３に格納された
オペレーティングシステム用のプログラムを実行するこ
とにより、本発明のログ採取機能が実現される。
【００８６】図１１は、ファイルシステム上で動作する
ログ採取機能の構成図である。図のように、ファイルを
管理するためのメタボリューム１１１〜１１３も複数設
けられている。メタボリューム１１１〜１１３には、そ
れぞれメタデータが格納されている。メタデータは、フ
ァイルの格納場所等を管理するために必要な情報を有し
ている。
【００８７】ログボリューム１２０は、ログ１２２を格
納するための二次記憶装置である。ログボリューム１２
０には、ログ１２２の他にボリューム管理情報１２１が
格納されている。
【００８８】メタキャッシュ１３０は、メタデータを操
作するためのメモリ上の領域である。メタキャッシュ１
３０内には、操作対象となるメタデータ１３２とそのメ
タデータの割り当て管理情報１３１とが格納される。
【００８９】ログキャッシュ１４０は、複数のログバッ
ファ１４１〜１４４を有している。ログバッファ１４１
〜１４４のサイズは均一ではなく、大きなサイズのもの
や小さなサイズのものがある。これらのログバッファ１
４１〜１４４には、メタキャッシュ１３０内で更新され
たメタデータの複製がログとして格納される。
【００９０】ログキャッシュ１４０とは別にログライト
バッファ１５０が設けられている。ログライトバッファ
１５０には、トランザクションの処理が終了した時点
で、ログバッファ１４１〜１４４内のログが転送され
る。
【００９１】この例では、複数のトランザクション１０
１〜１０３が並列動作している。このトランザクション
１０１〜１０３は、ファイルシステムオペレーションを
分割したものである。
【００９２】実際にＩ／Ｏを行うのは２つのデーモンで
あり、それぞれをメタライトデーモン１０４、ログライ
トデーモン１０５と呼ぶ。ログライトデーモン１０５が
ログをログ専用の二次記憶装置であるログボリューム１
２０に出力する。メタライトデーモン１０４は、ログボ
リューム１２０に対してログが出力されたことを確認し
た後、そのログに対応するメタデータをメタデータ専用
の二次記憶装置であるメタボリューム１１１〜１１３に
出力する。
【００９３】さらに、本発明のログ採取機能では、以下
のような特徴を有している。第１の特徴は、各メタデー
タに対応するメタデータ管理情報として、メタボリュー
ムを識別する情報が付加されていることである。これ
は、大規模ファイルシステムに対応するためのものであ
る。すなわち、複数の二次記憶装置がメタボリューム１
１１〜１１３として定義される場合に、メタキャッシュ
１３０上のメタデータ管理情報にそのメタデータが存在
するボリュームの情報を持たせている。
【００９４】図１２は、メタデータ管理情報を示す図で
ある。メタデータ管理情報には、「ボリューム番号」、
「メタデータ番号」、及び「メタデータポインタ」が登
録されている。「ボリューム番号」には、対応するメタ
データが存在するボリューム番号が登録されている。
「メタデータ番号」には、ボリューム毎におけるメタデ
ータ管理番号が登録されている。すなわち、システムが
認識するボリュームのデバイス番号とそのボリューム内
の位置から算定される数値によってメタデータが管理さ
れ、メタデータ自体がそれらの値を管理情報として保持
する。「メタデータポインタ」には、メタデータの実体
のある場所を指し示している。
【００９５】このようなメタデータ管理情報を有するメ
タデータの内容が更新されると、更新後のメタデータの
内容がログとしてログバッファに記録されるとともに、
メタデータ管理情報の内容がログに記録される。
【００９６】図１３は、ログバッファの形式を示す図で
ある。ログバッファには、「ＢＥＧＩＮマーク」、「ボ
リューム番号」、「メタデータ番号」、「メタデータ実
体」、及び「ＥＮＤマーク」の情報を含んでいる。
【００９７】ファイルシステムを復元する際には、ログ
内に記されているボリューム番号によって、そのログに
よって復元すべきメタデータの存在するメタボリューム
が認識される。これにより、従来技術のようにファイル
システム復元時にメタデータ番号からその存在すべきボ
リュームを決定するよりも速度向上が望め、システムダ
ウン後の大規模ファイルシステムにおいてもログ機構導
入によるファイルシステム復元時間の短縮が有効に機能
する。
【００９８】第２の特徴は、メタキャッシュ１３０内で
更新されたメタデータが、それぞれの管理構造にリンク
ポインタを持つことである。ログとしてログボリューム
１２０に記録されたメタデータはメタライトリストに繋
がれ、メタボリュームヘ反映が完了した時点でこのメタ
ライトリストから外される。さらに、ログとして記録さ
れているログボリューム１２０内の位置情報をも、メタ
ライトリスト内に持つ。このログボリューム内位置情報
をリストを辿って検索することによって、システムダウ
ン時に必要とされるログの範囲を特定することができ
る。そこで、ここから得られる有効範囲情報をログボリ
ューム１２０の特定位置に設けたボリューム管理情報１
２１内に記録する。有効範囲情報を記録し、ファイルシ
ステム復元時にそこに含まれるログのみをリプレイする
ことにより、ログボリューム全体を検索する必要がなく
なり、ログボリューム全体を読み込む必要のある、有効
範囲情報を記録しない従来の方式よりもファイルシステ
ムの復元時間をさらに短縮することができる。
【００９９】ところで、ログ機構はシーケンシャル性を
持ったディスクアクセスを行うことで、記録すべき内容
をヘッドシークすることなしにディスクヘ保存でき、デ
ィスクアクセス時間の短縮を図っている。ところが、本
手法を採用した場合、メタデータのメタボリューム反映
時、ログボリュームヘの書き出し時に、ログボリューム
の特定位置に有効範囲情報を書き出すこととなる。これ
ではシーク削減の意図が全く意味を成さない。
【０１００】そのため、本実施の形態ではある程度のイ
ンターバルを空けて、有効範囲情報は書き出すように工
夫した。変更がある度に、常に書き込まれるわけではな
いため有効範囲情報として保存されている情報には若干
の誤差が含まれてしまう。ファイルシステム復元時にそ
の誤差を吸収する必要がある。
【０１０１】図１４は、有効範囲を説明する図である。
図中において、「●」で示すのが、まだメタボリューム
に反映が終了しておらず、ファイルシステム復元に必要
なログを意味する。「○」で示すのは、メタボリューム
に反映が完了したことによって、ファイルシステム復元
時には利用しなくても良いログである。
【０１０２】従来のファイルシステムにおいて、ログを
用いたファイルシステム復元では、ログボリューム全体
を検索し，ログに記録されたシーケンス番号から、最古
のログを求め、たとえそれがメタボリュームに反映済み
の、利用しなくても良いログであっても利用して、ログ
ボリューム全体のログを用いていた。
【０１０３】本発明では、ある時点で有効範囲情報を書
き出した時の有効範囲が示されている。その後、有効範
囲を書き出さずに、メタボリュームヘの反映が進み、ま
た、別のトランザクションのログがログボリュームに書
き出されたことによって、実際の有効範囲と有効範囲情
報とはズレを生じている。この時点でシステムがダウン
し、ログを用いてファイルシステムを復元する場合に
は、多少のムダが生じるが、有効範囲情報が示す先頭位
置から、ログを利用する。利用すべきログの末端は有効
範囲情報以降の一定範囲を検索しなければならないが、
その検索は有効範囲情報を書き込むインターバルに依存
し、範囲が限られている。
【０１０４】第３の特徴は、ログに対してトランザクシ
ョン終了時にシーケンス番号を与え、その番号にはデー
タサイズが肥大化することを考慮に入れた上で、十分大
きいデータ型を適用することである。データ型の大きさ
は、コンピュータ自身の使用可能年数の間使い続けても
枯渇しない程度のサイズとする。例えば、システムの日
時表記を４桁の十進数「１９９９」で表していた場合、
西暦１万年まで使用されることは想定されていない。そ
の場合、西暦９９９９年まで使用可能なデータ型とすれ
ば、ログに対するシーケンス番号がオーバーフローして
逆転することがないことを保証することができ、それに
より、ログボリューム全体をゼロクリアして初期化する
必要が生じない。具体的には、データ型を６４ビット型
とすれば、オーバーフローすることは現実にはありえな
い（４万年ほど耐えられるものと思われる）。ファイル
システム管理情報、各トランザクションのログ、有効範
囲情報にこのシーケンス番号を含め、ログボリュームに
記録する。このように、ログに与えるシーケンス番号の
データ型に十分大きいものを適用することにより、通常
の運用時にトランザクションが動作する毎にインクリメ
ントしても、オーバーフローは現実には起こり得ない。
【０１０５】さらに、スーパブロックと呼ばれるファイ
ルシステム全体の管理情報にこのシーケンス番号を含
め、正常なアンマウント処理時及びファイルシステム復
元時にスーパブロックに含まれるシーケンス番号を正し
く設定し、次回のマウント時にそこから得られる値を用
いる。これにより、シーケンス番号は必ず昇順となるこ
とが保証され、ファイルシステム復元時に新しいログを
古いものと取り違えないことが保証される。
【０１０６】シーケンス番号の順序性を保証することに
よって、ファイルシステム復元時にログボリュームをゼ
ロクリアしなくとも、常に正しいログを利用することが
可能となり、ファイルシステム復元時にログボリューム
全体をゼロクリアするのに比べ、大幅な時間短縮が可能
となる。
【０１０７】以上の理由により、ログの最大のメリット
であるファイルシステム復元の時間短縮がより一層有効
に機能することが可能となる。第４の特徴は、トランザ
クションによって更新されたメタデータが、そのメタデ
ータの属性に応じ、再度同一のトランザクションにおい
て更新される可能性のあるメタデータであった場合に
は、更新の時点ではログバッファにはコピーせず、リス
ト構造（トランスリスト）によって管理することであ
る。
【０１０８】そして、同一トランザクション内で複数回
更新されるメタデータとして、領域割当て管理情報をリ
スト構造で管理し、トランザクション進行中にはその中
途段階のログは採取しない。トランザクション終了時に
リスト構造を辿って、トランザクションの更新の最終状
態のみを一括してログとすることによって、ログの縮小
が図られ、それに伴いファイルシステム復元時間の短縮
が可能となる。
【０１０９】具体的には、メタキャッシュ１３０内のメ
タデータを管理する構造にトランスリストヘのリンクポ
インタを持たせることによって実現している。トランザ
クションによって更新されたメタデータは、ただ一回し
か更新されないことが分かっているメタデータである場
合には、その時点でログバッファヘコピーされるが、以
降もトランザクション進行中に更新される可能性がある
場合には、このリンクポインタを用いてリスト構造に繋
がれる。メタデータの更新可能性の有無は、トランザク
ションの種別で判断する。例えば、データ領域の空きな
どを管理するためのトランザクションでは、何度もメタ
データが更新される。
【０１１０】そして、トランザクションが終了する時に
このトランスリストを辿り、メタデータの最終形態をロ
グバッファヘコピーする。すると、結局はトランザクシ
ョンが同一メタデータを複数回更新しても、最終形態の
一回だけのログ採取で済まされる。
【０１１１】図１５は、ログ採取処理のフローチャート
である。この処理は、オペレーティングシステムを実行
するＣＰＵが行う処理である。以下、ＣＰＵがオペレー
ティングシステムを実行することにより実現する機能
を、単に「システム」ということとする。 ［Ｓ１］トランザクションの開始宣言を行う。 ［Ｓ２］ログ採取要求を行う。 ［Ｓ３］対象メタデータの更新可能性の有無を判断す
る。更新可能性があればステップＳ５に進み、そうでな
ければステップＳ４に進む。 ［Ｓ４］ログバッファへメタデータをコピーし、ステッ
プＳ２に進む。 ［Ｓ５］対象メタデータはトランスリストに繋がれてい
るか否かを判断する。トランスリストに繋がれていれば
ステップＳ７に進み、そうでなければステップＳ６に進
む。 ［Ｓ６］メタデータ毎にトランスリストに繋ぐ。 ［Ｓ７］トランザクションの処理が終了するか否かを判
断する。終了するのであればステップＳ８に進み、そう
でなければステップＳ２に進む。 ［Ｓ８］トランザクション終了宣言を行う。 ［Ｓ９］トランスリストを辿り、繋がれている最終形態
のメタデータをそれぞれログバッファへコピーする。
【０１１２】このようにして、トランザクションの更新
の最終状態のみを一括してログとして保存することがで
きる。第５の特徴は、メタボリュームの割当て管理情報
は獲得用として通常の割当て管理情報の複製を新たに設
けたことである。ここで、割り当て管理情報として、ビ
ットマップを例に挙げて説明する。
【０１１３】図１６は、メタボリュームの割り当て管理
状況を示す図である。割り当て管理情報１３１には、使
用されているメタデータを管理するためのビットマップ
１３１ａが用意されている。ビットマップ１３１ａは複
数のブロックに分けられている。そして各ブロックのビ
ットマップの各ビットが「０」か「１」かによって、対
応するメタデータが空いているか否かが示される。そし
て、ブロックに分けられたビットマップの１つの複製が
作られ、獲得用ビットマップ１３１ｂとされる。
【０１１４】獲得時には、通常のビットマップ操作と同
様に未割り当て状態の領域の検索が行われる。この時、
検索対象として用いるのは獲得用ビットマップ１３１ｂ
である。獲得用ビットマップ１３１ｂ内から未割り当て
状態の領域（ビットが立っていない）が見つかった時に
は、その獲得要求には見つかったビット番号を返す。そ
して、獲得用ビットマップ１３１ｂ及び、その複製元と
なったビットマップの対応ビットを立てる。一方、獲得
用ビットマップ１３１ｂ内から未割り当て状態の領域が
見つからなかった時には、別のブロックのビットマップ
の複製を生成し、新たな獲得用ビットマップ１３１ｃと
する。
【０１１５】図１７は、ビットマップによるメタデータ
獲得処理を示すフローチャートである。この処理は、シ
ステムが行う処理である。 ［Ｓ１１］獲得要求を発行する。 ［Ｓ１２］獲得用ビットマップに空きがあるか否かを判
断する。空きがあればステップＳ２０に進み、そうでな
ければステップＳ１３に進む。 ［Ｓ１３］メモリ（メタキャッシュ１３０）上のビット
マップに「FreeDirty」フラグが立てられていないビッ
トマップが存在するか否かを判断する。存在すればステ
ップＳ１４に進み、存在しなければステップＳ１６に進
む。ここで「FreeDirty」フラグとは、一回以上の解放
処理が対象ビットマップに対してなされたことを意味す
る。 ［Ｓ１４］「FreeDirty」フラグが立てられていないビ
ットマップの中で、空きのあるものがあるか否かを判断
する。そのようなビットマップがあればステップＳ１５
に進み、そうでなければステップＳ１６に進む。 ［Ｓ１５］「FreeDirty」フラグが立てられておらず、
空きのあるビットマップの複製を、獲得用ビットマップ
に作成する。その後、ステップＳ２０に進む。 ［Ｓ１６］メタボリューム１１１〜１１３上のビットマ
ップに空きがあるか否かを判断する。空きのあるビット
マップがあればステップＳ１７に進み、そうでなければ
ステップＳ１８に進む。 ［Ｓ１７］メタボリューム１１１〜１１３上の空きのビ
ットマップをメモリ（メタキャッシュ１３０）上に読み
込み、ステップＳ１５に進む。 ［Ｓ１８］メモリ（メタキャッシュ１３０）上のビット
マップに「FreeDirty」フラグが立てられたビットマッ
プが存在するか否かを判断する。存在すればステップＳ
１９に進み、存在しなければ、獲得不可能と判断し処理
を終了する。 ［Ｓ１９］「FreeDirty」フラグが立てられたビットマ
ップをメタボリュームに反映し、「clean」状態にす
る。ここで「clean」状態とは、獲得、解放の処理が全
く行われていない状態を示す。その後、ステップＳ１３
に進む。 ［Ｓ２０］獲得用ビットマップのビットを立てる。 ［Ｓ２１］複製元ビットマップの同一ビットを立てる。 ［Ｓ２２］複製元ビットマップに「AllocDirty」フラグ
を立てる。ここで、「AllocDirty」フラグとは、対象ビ
ットマップから一回以上の獲得処理によって更新がなさ
れた場合に、そのビットマップの管理構造体内のフラグ
に立てる値である。「AllocDirty」フラグや「FreeDirt
y」フラグが立ったビットマップはログ採取対象であ
る。メタボリュームに反映された時にこれらのフラグは
落とされ、「clean」状態となる。
【０１１６】このようにして、空きのビットマップを獲
得できる。解放時にも、通常のビットマップ操作と同様
に、要求された領域が対応するビットの算出がまず行わ
れるが、対応するビットを落とす操作は、対象のビット
マップに対してのみ行い、仮にその対象ビットマップの
複製が獲得用ビットマップとして存在する場合にも、そ
の獲得用ビットマップに対しては行わない。
【０１１７】図１８は、解放処理のフローチャートであ
る。この処理は、システムが行う。 ［Ｓ３１］解放要求を出す。 ［Ｓ３２］対象ビットマップがメモリ（メタキャッシュ
１３０）上にあるか否かを判断する。対象ビットマップ
があればステップＳ３４に進み、そうでなければステッ
プＳ３３に進む。 ［Ｓ３３］メタボリューム１１１〜１１３上の対象ビッ
トマップをメモリ（メタキャッシュ１３０）上に読み込
む。 ［Ｓ３４］対象ビットマップの対応するビットを落と
す。 ［Ｓ３５］対象ビットマップに「FreeDirty」フラグを
立てる。
【０１１８】この一見複雑に見える作業によって、解放
した領域を即座に別の用途に利用してしまうことを回避
することが可能となり、システムダウン時に中途までし
か終了していなかった解放トランザクションが解放した
はずである領域は、解放される直前の状態のまま保全さ
れることが保証できる。
【０１１９】例えば、Ａというトランザクションが解放
処理、Ｂというトランザクションが獲得処理を行う場合
を考える。ここで、トランザクションＡの解放処理はト
ランザクションＢの獲得処理よりも先に行われ、かつ、
トランザクションＡはトランザクションＢよりも後に終
わる場合を例に挙げる。
【０１２０】図１９は、トランザクションの処理の獲得
と終了の状況を示す図である。この図において、各トラ
ンザクションは「ＢＥＧＩＮ」で始まり、「ＥＮＤ」で
終わることを意味し、トランザクションの「○」が解放
処理を、「●」が獲得処理を意味する。
【０１２１】上図のように、トランザクションＡの解放
処理がトランザクションＢの獲得処理よりも先に行わ
れ、かつ、トランザクションＢのほうがトランザクショ
ンＡよりも先に終了した場合に従来のログ採取方式では
問題が生ずることは既に述べた。
【０１２２】本発明が提案する手法を用いれば、トラン
ザクションＢが獲得する領域がトランザクションＡが解
放した領域となることは基本的にはなく、領域枯渇状態
に近く、どうしてもこの領域を獲得せねばならない時に
は、一旦、該当ビットマップをメタボリュームに反映し
た後、獲得処理が行われる。これにより、ファイルシス
テム復元時に必要とされる、メタボリュームに未反映な
メタデータを対象とするログを用いた復元では、管理情
報上、二重獲得と見えるようなログは残り得ない。
【０１２３】また、トランザクションＢのログにはトラ
ンザクションＡの解放処理が記録されないため、トラン
ザクションＢのログよりも後に復元に用いるトランザク
ションＡのログによって、トランザクションＢが獲得し
た領域を変更されることもありえない。
【０１２４】第６の特徴は、前述のようにログ機構の導
入にあたり、獲得・解放操作のログとして、その獲得・
解放した対象の情報（このビットを立てた・落した）の
みを記録することである。これによって、複数の獲得・
解放要求に対して、要求の発生後、トランザクションの
終了時点までをシリアライズすることなくログ管理で
き、かつログ採取量は減少し、複数トランザクション動
作による変更をメタボリュームヘ反映する回数をも減少
させることができる。
【０１２５】第７の特徴は、ログキャッシュ１４０を複
数のログバッファで管理し、この時、いくつかの異なる
サイズとすることである。ログキャッシュ１４０を分割
して複数のログバッファとして管理することによって、
トランザクションの独立性を確立することが容易となる
とともに、有限なメモリ空間を有効に活用することが可
能となる。
【０１２６】まず、トランザクションがメタデータを更
新するより以前に、自分がメタデータを更新する旨、シ
ステムに宣言する。この時、トランザクションの種別よ
り予測されるログ採取情報に応じて、最適なサイズのロ
グバッファがシステムより与えられ、トランザクション
進行に伴い蓄積されるログはここへ溜められることとな
る。上記第６の特徴で説明した手法に加え、トランザク
ション毎に異なるログバッファを用いることによって、
複数のトランザクション更新の混じらない、純粋なログ
として残すことが可能である。
【０１２７】第８の特徴は、上記第７の特徴で説明した
手法に加え、トランザクションの開始時に予測したログ
採取量よりも多くのログを採取しなければならなかった
場合に、与えられたログバッファから、さらに大きいロ
グバッファへ移行することである。システムの状況に応
じて、トランザクションによって残されるログのサイズ
は変動し、その差異を複雑な処理を必要とせず、かつ、
有限なメモリ空間を有効に活用して吸収することが可能
である。
【０１２８】第９の特徴は、ログバッファに入りきらな
い場合には、ログボリュームへ中間ログを書き出すとと
もに、中間ログを書き出すことによる矛盾の発生を防止
する機能を備えたことである。
【０１２９】ログボリュームに対するＩ／Ｏ発行を減少
させるために、ログライトバッファと呼ぶ二次キャッシ
ュ領域を設けている。終了したトランザクションのログ
は、ログバッファからこのログライトバッファヘ移さ
れ、適時にログライトデーモン１０５によってログボリ
ュームヘ書き出される。この適時とは、負荷が低い場合
には一定の周期で良いが、トランザクションによるメタ
データの更新量が多く、最大のログバッファでも収まら
ない場合などには強制的なＩ／Ｏ発行が必要とされる。
このような場合において、中途の段階でのログの出力で
は、まだ更新されていない（かもしれない）メタデータ
を含めた書き出しをファイルシステムの整合性を保つた
めには必要である。
【０１３０】このように有限なメモリ空間を有効活用す
ることを考慮した上で、ログバッファ内に収まりきらな
いログをトランザクション途中で出力する時に、残され
るログによって復元されるファイルシステムの整合性を
正当なものとするための手法を提案している。
【０１３１】ファイルシステムに対する負荷がそれほど
高くない場合には、ログのログボリュームに対するＩ／
Ｏを極力少なくするために事前に与えられた周期に応じ
て定期的にデーモンによって行われる。しかし、ログバ
ッファが枯渇し、以降のトランザクション進行で溜めら
れるログが収まらないと判断された時、部分的なログと
して、この時点のログをログボリュームヘ出力する。こ
の時、まだ更新されていない情報をもログに出力する。
例えばファイルを追加ライトするトランザクションの場
合は、部分的なログを出力する時点でのファイルサイズ
や時刻情報を合わせてログに記録する。これによって、
部分的であるはずのこのログを、ファイルシステム復元
時には完結した１つのトランザクションのログと同等に
扱うことが可能となり、ファイルシステム復元時に複雑
な考慮の必要なしに、望ましい状態にファイルシステム
を復元することが可能となる。
【０１３２】図２０は、ログバッファへのログの格納状
況を示す図である。この例では、２種類のサイズのログ
バッファ１４１〜１４６が設けられている。ログバッフ
ァ１４１〜１４５は通常のサイズであり、ログバッファ
１４６が大きなサイズである。
【０１３３】また、ログバッファ１４１〜１４６を管理
するためのログバッファ管理テーブル１４８，１４９が
設けられている。ログバッファ管理テーブル１４８は、
ログバッファ１４１〜１４６に対応するフラグビットを
有している。そして、使用されているログバッファに対
応するフラグビットの値が「１」に設定され、未使用の
ログバッファに対応するフラグビットの値は「０」に設
定されている。同様に、大きいサイズのログバッファ１
４６に対応するログバッファ管理テーブル１４９もフラ
グビットを有しており、そのフラグビットの値によっ
て、ログバッファ１４６が使用されているか否かを管理
している。
【０１３４】ログキャッシュ１４０内の各ログバッファ
１４１〜１４５のうち、ログバッファ１４３とログバッ
ファ１４５とが現在利用中であることを意味するため
に、「●▲」などの記号を用いた。ここで、ログバッフ
ァ１４５には多くのログが溜まっており、既に満杯の状
態となっている。このように通常のサイズのログバッフ
ァ１４１〜１４５では容量が足りなくなった際には、そ
のログを大きいサイズのログバッファ１４６に移動す
る。そして、トランザクションが継続している間は、更
新されたメタデータの内容を、随時ログバッファに格納
していく。ここで、トランザクションが終了したら、そ
のトランザクションに対応するログバッファの内容をロ
グライトバッファ１５０へ転送する。
【０１３５】ログライトバッファ１５０には、複数のバ
ッファ１５１，１５２が設けられており、それらのバッ
ファ１５１，１５２にログが書き込まれる。ログライト
バッファ１５０内のログは、ログライトデーモン１０５
によって随時ログボリュームに書き込まれる。
【０１３６】図２１は、ログ採取手順を示すフローチャ
ートである。これはシステムが行う処理である。 ［Ｓ４１］BEGIN宣言を行う。 ［Ｓ４２］ログバッファの予約をする。 ［Ｓ４３］ログ採取要求を行う。 ［Ｓ４４］現在のログバッファに今回のログが収まるか
否かを判断する。収まるのであればステップＳ５１に進
み、収まらないのであればステップＳ４５に進む。 ［Ｓ４５］現在のログバッファより大きいログバッファ
が存在するか否かを判断する。存在すればステップＳ４
６に進み、そうでなければステップＳ４７に進む。 ［Ｓ４６］現在のバッファから大きいバッファへ内容を
コピーし、ステップＳ４４に進む。 ［Ｓ４７］トランザクションに与えられたパラメタをロ
グ採取する。 ［Ｓ４８］現時点のファイル状態を正しく表す管理情報
をログ採取する。 ［Ｓ４９］現在の中途段階のログをログライトデーモン
１０５に書き出させる。 ［Ｓ５０］現在のログバッファをクリアする。 ［Ｓ５１］ログを採取する。 ［Ｓ５２］ログ採取要求を終了する。 ［Ｓ５３］ＥＮＤ宣言あるか否かを判断する。END宣言
があればステップＳ５４に進み、そうでなければステッ
プＳ４３に進む。 ［Ｓ５４］END宣言を行い、処理を終了する。
【０１３７】第１０の特徴は、トランザクションが完了
する前に、システムダウンが発生した場合に備え、分割
して出力するログにはトランザクションに与えられたパ
ラメタを含め、ファイルシステム復元時にそのパラメタ
を元に、再度トランザクションを実行することである。
【０１３８】さらに、この部分的なログにトランザクシ
ョンに与えられたパラメタを記録し、ファイルシステム
復元時にそれを用いて、通常のログだけでは中途で終わ
った状態までしか復元できないファイルを、トランザク
ションが終了した状態にまでファイルシステムに反映す
ることが可能となる。
【０１３９】図２２は、ファイルシステム復元処理を示
すフローチャートである。これはシステムが行う処理で
ある。 ［Ｓ６１］システムダウン等が発生する。 ［Ｓ６２］ファイルシステムの異常を検知する。
【０１４０】以降、ファイルシステム復元処理を行う。 ［Ｓ６３］ログ開始マークを検出する。 ［Ｓ６４］ログ開始マークに対応するログ終了マークが
存在するか否かを判断する。ログ終了マークが存在すれ
ばステップＳ６５に進み、ログ終了マークが存在しなけ
ればステップＳ６６に進む。 ［Ｓ６５］開始マークから終了マークまでのログを用い
て復元処理を実行する。その後、ステップＳ６３に進
む。 ［Ｓ６６］対象トランザクションが以前のログだけで完
結するか否かを判断する。完結するのであれば復元処理
を終了し、完結しないのであればステップＳ６７に進
む。 ［Ｓ６７］ログに記録されたパラメタを読み込む。 ［Ｓ６８］トランザクションとして行いたかった処理を
理解する。 ［Ｓ６９］ファイルに対して直接処理を再実行する。そ
の後、復元処理を終了する。
【０１４１】これにより、オペレーションのセマンティ
クスを保証したファイルシステムの復元が可能となり、
従来技術では完全に元に戻す、または完全に再実行する
ことが不可能であったトランザクションを、完全に再実
行することによってファイルの整合性をも回復すること
が可能となる。
【０１４２】第１１の特徴は、メタデータを更新するト
ランザクションが更新処理を行う前に、その旨をシステ
ムに対し宣言することである。さらに、システムは宣言
を受け入れるか否かを判断する機構を持つことである。
ここでは、以下の条件の場合には新規のトランザクショ
ンの受け入れを拒否し、拒否されたトランザクションは
再度認可が下りるまで待合わせなければならない。 ・メタキャッシュ１３０がフルに近い状態にある場合。 ・トランザクションの多重度が、システムで規定された
値を既に越えていた場合。 ・ログボリュームに残されたログの大部分が有効なログ
状態である場合。
【０１４３】これらの場合に、ファイルシステムが新規
トランザクションの受け入れを拒否し、トランザクショ
ンの多重度を宣言することによって、結果としてダーテ
ィなメタデータの数を制限することが可能となり、メタ
キャッシュ１３０の空き領域枯渇などを要因とするハン
グアップ状態に陥ることを回避することが可能となる。
特に、分割ログとしてログ採取しなければならないトラ
ンザクションが動作中に、新規トランザクションの開始
を拒否することは、システムの状態を正常に維持する上
で効果が高い。
【０１４４】第１２の特徴は、新規トランザクションの
受け入れ拒否の機構をログボリューム内の有効ログの割
合に応じて適用することにより、単一の、多数のメタデ
ータを更新するトランザクションのみならず複数のトラ
ンザクションが更新したメタデータによって空き領域の
減少に伴うハングアップ状態をも回避することである。
【０１４５】以下に、第１１の特徴と第１２の特徴とを
含むトランザクションの受け入れ処理について説明す
る。図２３は、新規トランザクションの受け入れ許否判
定処理を示すフローチャートである。 ［Ｓ７１］トランザクションを行うプロセス（以下、単
にトランザクションという）が、トランザクション処理
を開始する。 ［Ｓ７２］「BEGIN」宣言を行う。この際、オペレーテ
ィングシステム（以下、単に「システム」という）に対
して問い合わせを行う。 ［Ｓ７３］トランザクションは、システムからの回答待
ち状態となる。システムより「ＯＫ」の回答を受け取っ
たらステップＳ８２に進む。 ［Ｓ７４］トランザクションからの問い合わせを受けた
システムが、パラメタの評価を開始する。 ［Ｓ７５］システムは、既に多重度が規定値より上であ
れるか否かを判断する。多重度が規定値より上であれば
「ＮＧ」としてステップＳ８１に進み、そうでなければ
「ＯＫ」としてステップＳ７６に進む。 ［Ｓ７６］システムは、現在サブトランザクションが動
作中であるか否かを判断する。サブトランザクションが
動作中であれば「ＮＧ」としてステップＳ８１に進み、
そうでなければ「ＯＫ」としてステップＳ７７に進む。
ここでサブトランザクションとは、ログを複数に分割し
て格納する場合に、１つのログバッファにログを格納で
きるような処理単位に分割されたトランザクションであ
る。 ［Ｓ７７］システムは、メタキャッシュ１３０に十分な
空きがあるか否かを判断する。十分な空きがなければ
「ＮＧ」としてステップＳ７９に進み、十分な空きがあ
れば「ＯＫ」としてステップＳ７８に進む。 ［Ｓ７８］システムは、ログボリュームに上書き可能領
域が少ないか否かを判断する。上書き可能領域が十分に
なければ「ＮＧ」としてステップＳ７９に進み、十分な
上書き可能領域があれば「ＯＫ」としてトランザクショ
ンに対して「ＯＫ」の回答を返す。 ［Ｓ７９］システムは、ログライトデーモン１０５を起
動する。 ［Ｓ８０］システムは、メタライトデーモン１０４を起
動する。 ［Ｓ８１］システムは、ＮＧ条件が解消されるまでスリ
ープ状態で待つ。ＮＧ条件が解消されたら、ステップＳ
７５に進む。 ［Ｓ８２］トランザクションは、システムからの「Ｏ
Ｋ」の回答を受け取ったら、多重インクリメント処理を
行う。 ［Ｓ８３］トランザクションは、「BEGIN」処理を終了
する。 ［Ｓ８４］トランザクションは、処理に応じて、メタデ
ータをキャッシュに読み込み、その度に空き量をデクリ
メントする。分割ログ化するなら他トランザクションの
開始を拒否するようにシステムに依頼する。 ［Ｓ８５］トランザクションは、「END宣言」を行う。 ［Ｓ８６］トランザクションは、多重度をデクリメント
する。 ［Ｓ８７］トランザクションは、必要に応じてログ採取
を繰り返した後、自己のトランザクション処理を終了す
る。
【０１４６】次に、本発明を適用したシステムの具体的
な処理内容について説明する。本発明の全ての特徴を備
えたシステムにおけるログ採取手順は以下のようにな
る。ファイルシステムオペレーションを分割したトラン
ザクションはメタデータを更新するより前に、自分がこ
れからメタデータを更新する旨を宣言する（ＢＥＧＩ
Ｎ）。ＢＥＧＩＮ時にトランザクションに対し、独立し
たログバッファが割当てられる。この時、既にトランザ
クションの並列動作数が非常に多かったりメタキャッシ
ュ１３０域の利用率が高い場合には、システムによって
ＢＥＧＩＮ宣言が拒否される。ＢＥＧＩＮ宣言を拒否さ
れたトランザクションはその許否理由が解消されるま
で、待ち合わせなければならない。
【０１４７】更新が完了したメタデータは、ＢＥＧＩＮ
時に割り当てられたログバッファヘコピーされる。それ
と同時にメタデータ種類に応じたリストへ繋がれる。更
新すべき全てのメタデータを更新し終わったトランザク
ションは、そこで完了を宣言する（ＥＮＤ）。ＥＮＤ時
には、これまで溜めたログバッファの内容をログ専用の
二次キャッシュであるログライトバッファヘ移動し、さ
らに、まだログバッファヘコピーされていなかったメタ
データをログライトハッファヘコピーする。
【０１４８】また、ＥＮＤ時にメタデータの種類に応じ
て繋がれていたリストから、そのトランザクションが更
新した全てのメタデータを「ログ待ちリスト」へ繋ぎ替
える。
【０１４９】以上で非同期要求のトランザクションは終
了することができる。トランザクションが同期要求であ
った場合には、ログを書き出すまで待ち合わせなければ
ならない。
【０１５０】ログの書き出しは独立したデーモン（ログ
ライトデーモン１０５）が行う。このデーモンの起動契
機は、同期要求トランザクションによる起動要求（ｗａ
ｋｅｕｐ）、メタキャッシュ１３０の空き状態監視機構
による起動要求（ｗａｋｅｕｐ）、及びタイマである。
【０１５１】起動したログライトデーモン１０５は複数
のトランザクションのログがまとめられたログライトバ
ッファを１つのＩ／Ｏとして発行する。そして、ログ待
ちリストから「書き出しリスト」ヘメタデータを移動す
る。
【０１５２】メタボリュームヘＩ／Ｏを発行するのは、
メタライトデーモン１０４の役割である。メタライトデ
ーモン１０４は書き出しリストに繋がれたメタデータを
順に非同期ライトによってメタボリュームに反映する。
メタライトデーモン１０４の起動契機は、ログバッファ
の空きが少なくなった時、ログボリュームの空きが少な
くなった時、及びタイマである。
【０１５３】以上で、メタデータを更新するトランザク
ションの開始から、更新されたメタデータがメタボリュ
ームに反映されるまでの大まかな流れである。以降に、
ログの採取とそのディスク反映手法、そして、メタデー
タのディスク反映の処理について詳細に説明する。 （１）ログの構造 （１．１）ログボリューム ログボリュームに格納される情報は、以下のような情報
である。
【０１５４】ログボリュームにはスーパブロック、ボリ
ューム管理情報が先頭にある。その次にログの有効範囲
を示す構造体を記録する。構造体は以下のメンバを持
つ。 ・有効ログ先頭のログボリューム内オフセット ・有効ログ先頭のログシーケンス番号 ・有効ログ末尾のログボリューム内オフセット ・有効ログ末尾のログシーケンス番号 ただし注意しなければならないのは、ここで先頭・末尾
と言っているのは、真の値ではない可能性があることを
リプレイ時に考慮しなければならない点である。なぜな
ら、ログはボリュームをシーケンシャルアクセスするこ
とによってシーク時間の短縮を計っているが、このよう
にボリュームの一部へ毎回アクセスしたのでは、そのシ
ーケンシャル性が損なわれてしまう。そのために、ログ
の書き出し毎にはこの有効範囲の書き出しは行わず、数
回に一回、書き出している。
【０１５５】これにより、上記構造体に収められたオフ
セットは正確ではないためにリプレイ時に検索が必要で
はある。しかしながら、全体を検索するよりも大幅に検
索量が減るため、利点は保持できるものと考える。
【０１５６】上記以外は、全て、メタデータの更新履歴
によって構成される。 （１．２）ログブロックの基本構造 ログボリューム１２０内に残されたログ（メタデータの
更新情報）は基本的にはトランザクション単位である。
これをログブロックと呼ぶ。しかし、キャッシュ域フル
などによって、１つのトランザクションを一度にまとめ
ることができない場合は複数の分割ログに分ける。この
分割ログをサブトランザクションログと呼ぶ。
【０１５７】サブトランザクションログをリプレイする
ことによって、ファイルシステムの整合性が保てるよ
う、その内容は工夫されている。しかしながら、トラン
ザクションの途中までのサブトランザクションをリプレ
イしたのでは、トランザクション全体が終わっていない
ことから、ファイルシステムとしての整合性が保てて
も、ファイルの中身は異常であるという状態に陥ってし
まうことが考えられる。
【０１５８】この状態を回避するために、そのサブトラ
ンザクションに別れたトランザクションがどのようなオ
ペレーションであったかをログに採取する（オペレーシ
ョンログ）。ログリプレイ時には、サブトランザクショ
ンをリプレイした後、オペレーションログをリプレイヤ
が再実行することによって、トランザクション全体が終
わった状態とすることが可能である。
【０１５９】サブトランザクション化する可能性のある
トランザクションは全体終了時に「終わったこと」をロ
グに記録し（最終ＥＮＤマーク）、リプレイヤはその有
無を調べてオペレーションログの実行を判断する。 （１．３）ログの採取形式 メタデータの更新情報は該当するメタデータの管理構造
単位で採取する。また、メタボリュームの管理構造であ
るビットマップはその更新部分だけのログ採取とする、
スーパブロックについては特殊であり、データ空き容量
についてのみログ採取を行う。 （１．３．１）ｉｎｏｄｅ、Ｖデータ、空き管理情報 ファイルの管理情報であるｉノード、Ｖデータと呼ぶデ
ィレクトリやシンボリックリンクデータや空き管理情報
のメタデータ本体は、それらのＩ／Ｏ単位（ブロック単
位）でのログ採取を行う。
【０１６０】これは、ファイルシステム整合性チェック
処理であるｆｓｃｋによるログリプレイ時の処理を簡略
化することを意識している。変更された部分だけをログ
採取した場合、ログリプレイ時には、該当ブロックの算
定→読み込み→変更部分の更新→再度書き込み、とステ
ップが増えてしまう。しかし、ブロック全体のログ採取
によって、リプレイ時にはメタボリュームにログ情報を
上書きするだけでよい。
【０１６１】ｉノード本体やディレクトリブロックなど
のＶデータは、更新中はファイルのロックで保護されて
いる。しかしながら、空き管理情報についてはファイル
のロックでは保護されない。そのため、トランザクショ
ン途中で他トランザクションによって更新され、そのト
ランザクションが追い越して先に終わってしまうと、ロ
グには古い情報が後に残されてしまい、リプレイすると
ファイルシステムに不整合が生じてしまう。
【０１６２】そのため、空き管理部については、ここで
は更新するトランザクションが並行動作しないことを保
証することによって実質的な排他制御を行い、他のメタ
データと同じ採取形式とした。 （１．３．２）ビットマップ メタデータの割り当て状況を管理するビットマップも空
き管理部と同様にファイルのロックで保護されていな
い。そのため、ビットマップ全体のログ採取を行うと、
そのログには複数のトランザクションによる更新が含ま
れてしまう可能性がある。特に、トランザクションの追
い越しが発生すると、新しいはずのログによって、ビッ
トマップの情報が古く書き戻されてしまうことが考えら
れる。
【０１６３】そこで、ビットマップのログ採取は更新部
分だけとする。更新部分とは、あるビットが０になっ
た、あるいは１になったと記録するだけである。それに
より、トランザクションが並行動作してもそれぞれのト
ランザクションが更新した内容のみがログに残されるた
め、メタデータの後退は起こり得ない。
【０１６４】注意すべきは、ある領域を解放（「１→
０」）した後、他トランザクションがそこを獲得（「０
→１」）した場合である。トランザクションの追い越し
が発生すると、ログリプレイによって獲得した領域を解
放してしまう。
【０１６５】これについては、アロケート用ビットマッ
プを１つ定め、複製を用いて操作を行うことによって回
避する。 （１．４）ログの記録構造 （１．４．１）一般ログ 有効状態であっても、ある程度の複数スレッドが同時に
進行することを許す。これは性能要件より必須である。
しかし、ログボリューム内のログは前述の通り、トラン
ザクション毎に保存する。１つのトランザクション結果
をログに記録する際、ログは以下のパーツで構成する。 １）ＢＥＧＩＮマーク ２）ヘッダ ３）更新内容 （２）＋３）の繰り返し） ４）ＥＮＤマーク これを以下、ログブロックと呼ぶ。ログブロックはログ
ボリュームの物理ブロック境界から始まるが、その終わ
りは物理ブロック境界であるとは限らない。 １）ＢＥＧＩＮマーク トランザクションの開始時に作成される情報であり、以
下の内容を含む。 ・マジックワード ・トランザクションタイプ ・ログシーケンス番号 ・ログブロックサイズ マジックワード：１つのトランザクションが始まったこ
とを示すマジックワードを埋め込む。
【０１６６】トランザクションタイプ：ＢＥＧＩＮマー
クにトランザクションのタイプ（種類）を埋め込むこと
によって、その後ろの更新情報に含まれる内容の概要を
事前に知ることが可能。
【０１６７】ログシーケンス番号：ログに記録されたト
ランザクション毎にインクリメントされる数値。このカ
ウンタが最小のログブロックがそのログボリューム内で
最も古いトランザクションであることを示す。カウンタ
は６４ビット型とし、オーバーフローすることは現実に
はありえない（４万年ほど耐えられるものと思われ
る）。ログリプレイ時に、ログボリュームをゼロクリア
することにより、再度０から開始することも考えられる
が、リプレイ時間の短縮を考慮し、利用したログの最後
のシーケンス番号より昇順に採番することによりゼロク
リアを回避する。
【０１６８】ログブロックサイズ：ログブロックのＥＮ
Ｄマークまでのサイズを記録する。ＢＥＧＩＮマークの
先頭からＥＮＤマークの先頭までのサイズである。リプ
レイ時にはＢＥＩＧＮマークの先頭からこのサイズだけ
移動し、ＥＮＤマークの情報を参照して、ログの有効性
を判定する。 ２）ヘッダ 更新されたメタデータについて、その保管位置を特定す
るための情報であり、以下のメンバによって構成され
る。 ・メタデータタイプ ・メタボリューム番号 ・ボリュームローカルメタデータ番号 メタデータタイプ：更新情報の後方にある又データ更新
内容が何のメタデータであるのかを特定するために用い
られ、リプレイヤはここから更新内容のサイズを判断す
る。
【０１６９】メタボリューム番号：メタデータ管理で用
いているメタボリューム毎の番号を記録する。リプレイ
時には、この番号から書き戻すメタボリュームを決定す
る。ボリュームローカルメタデータ番号：メタデータ管
理で用いている、メタボリューム毎、メタデータ毎に０
から始まる値を記録する。リプレイ時には、この番号か
らメタボリューム内のブロック位置に変換し、更新内容
を書き戻す。これはブロック位置変換を削減することに
よるログ採取の高速化が狙いである。対象がビットマッ
プである場合には、変更されたビットが該当するメタデ
ータ本体のメタデータ番号を記載する（ビットマップ番
号ではない）。 ３）更新内容 メタデータ本体の場合には、更新内容が含まれるブロッ
ク（それぞれのメタデータの管理単位）である。例え
ば、ディレクトリブロックが更新された場合には１０２
４バイトのディレクトリブロック全体である。
【０１７０】ビットマップの場合には、全体ではなく、
ここには「０→１」または「１→０」という情報だけ記
録する。リプレイ時にはヘッダから該当するビットマッ
プを判定し、それを読み込み、ここの内容から該当ビッ
トを変更して書き戻す。 ４）ＥＮＤマーク ＢＥＧＩＮマークに対応するマジックワード、ログシー
ケンス番号、ログブロックサイズを記録する。
【０１７１】ＥＮＤマークがマジックワードとログ番号
だけでは、メタデータの内容によってはそれが偽りのＥ
ＮＤマークとして見えてしまい、リプレイの時に処理を
誤る可能性がある。これを回避するために、ＥＮＤマー
クは固有形式（メタデータを誤認することのない形式）
としなければならない。
【０１７２】ＢＥＧＩＮマークを固有形式としないの
は、ＢＥＧＩＮマークだけ書き出された時点で、システ
ムダウンした場合を考慮し、いずれにせよＥＮＤマーク
の識別ができなければならないからである。
【０１７３】固有形式とするために、固有の数値を６４
バイト分続ける。これにより、全てのメタデータがＥＮ
Ｄマークに化けることはなくなる。これに続けて、マジ
ックワード、カウンタ（ログ番号）、ログブロックサイ
ズを記録する。以降、ブロック境界まで、上記数値を埋
める。ＢＥＧＩＮマークに対応したＥＮＤマークを見つ
けることができないログ情報はリプレイしてはならない
（ログ書き出し途中にシステムが異常終了したことを意
味する）。 （１．４．２）巨大トランザクションのログ トランザクションが多くのメタデータを更新する場合に
は、ログバッファサイズ、ログボリュームサイズが有限
であることから、複数のサブトランザクションログに分
割する。サブトランザクションログはそれだけのリプレ
イによって、ファイルシステムの整合性は保たれる。し
かし、トランザクション全体のサブトランザクションロ
グをリプレイしなければ、ファイルの整合性が保てな
い。そのため、サブトランザクション途中でのシステム
ダウンを考慮し、オペレーションログ内部に含む。 １）ＢＥＧＩＮマーク ２）オペレーションログ ３）ヘッダ ４）更新内容 （３）＋４）の繰り返し） ５）ＥＮＤマーク （１）〜５）の繰り返し） （５’）最終ＥＮＤマーク） １）ＢＥＧＩＮマーク 一般ログのＢＥＧＩＮマークと同じ。ただし、サブトラ
ンザクションログとなりうるトランザクションは、書き
込みや削除など、データ領域を触るものや、領域管理に
関わるものに限定される。
【０１７４】これらのトランザクションがＢＥＧＩＮマ
ーク内で設定されていたら、そのログはサブトランザク
ション化している可能性があり、必すオペレーションロ
グが続いている（たとえ単一のサブトランザクションロ
グで構成されていても）。 ２）オペレーションログ サブトランザクション化したトランザクション（関数）
に与えられた引数をオペレーションログとして保存す
る。巨大トランザクションを対象としたＢＥＧＩＮマー
クの直後には必ずオペレーションログを配置する。オペ
レーションログは、最初にトランザクションヘ渡された
情報（このファイルをこれだけのサイズトランケートす
るとか、このファイルをこれだけアペンドライトするな
ど）である。
【０１７５】リプレイ時には、リプレイヤがファイルシ
ステムを直接操作して、ここで残されたオペレーション
ログを実行しなければならない。オペレーションログは
以下のメンバで構成される。 ・パラメタ１ ・パラメタ２ ・・・ リプレイヤはＢＥＧＩＮマーク内のトランザクションタ
イプを見ることによって、オペレーションログ部分に並
ぶパラメタ群のサイズ及び内容を知ることができる。 ３）ヘッダ 一般ログのヘッダと同じ。 ４）更新内容 一般ログの更新内容と同じ。 ５）５’）ＥＮＤマーク、最終ＥＮＤマーク 一般ログのＥＮＤマークと同じ意味合いを持ち、ＢＥＧ
ＩＮマークに対応するＥＮＤマークあるいは最終ＥＮＤ
マークが見つからない場合には、ＢＥＧＩＮマーク以降
の更新内容をリプレイしてはならない。
【０１７６】巨大トランザクションがサブトランザクシ
ョンに分割されず、単一のログブロックのみの場合に
は、ＥＮＤマーク部分には最終ＥＮＤマークが書き出さ
れる。複数のサブトランザクションログに分かれている
場合には、最後のログブロックだけ、ＥＮＤマークが最
終ＥＮＤマークに化ける（最後以外のログブロックには
通常のＥＮＤマークが書かれている）。
【０１７７】ＥＮＤマークは一般ログのＥＮＤマークと
同一であり、マジックワード、カウンタ（ログ番号）、
ログブロックサイズが記録されており、ブロック境界ま
で固有数値が埋まる。
【０１７８】最終ＥＮＤマークとＥＮＤマークの差は、
マジックワードのみである。最終ＥＮＤマークがトラン
ザクション全体の終了を表すことから、とても巨大なト
ランザクションが多くのサブトランザクションログに分
割されている場合には、全ての処理が完了する時にこの
最終ＥＮＤマークを出力する。すなわち、巨大トランザ
クションとして定義されるトランザクションについて、
通常のＥＮＤマークで終わるログブロックがいくつか見
つかったのに、最終ＥＮＤマークで終わるログブロック
が存在しない場合には、それは巨大トランザクションの
途中でシステムダウンが発生したことを意味し、ログリ
プレイヤがオペレーションログのリプレイを行わなけれ
ばならないことを意味する。 （２）ログの採取 （２．１）ログバッファの管理 ログをトランザクション単位にログボリューム１２０ヘ
出力するためには、メタデータの更新情報を一度、メモ
リ内に溜める必要がある。これをログバッファと呼ぶ。
ログバッファはマウント時にまとめて用意し、ファイル
システム利用中にメモリの追加獲得は行わない。
【０１７９】トランザクション毎のログ採取とし、ま
た、トランザクション動作中に他のトランザクションが
並行動作することを狙い、ファイルシステム毎にログバ
ッファを複数持つ。その数は並行動作を許すトランザク
ション数によって決められる。
【０１８０】並行動作数を限定することはログ機能追加
による性能劣化要因の１つとなるが、 ・ログリプレイ時の処理を単純化 ・巨大なログバッファを分割して使うことによる複雑さ
の回避 などのメリットが考えられるため、この方式とする。
【０１８１】各トランザクションは開始時に割り振られ
たログバッファにログを作成し、トランザクション終了
時にまとめてログライトバッファヘコピーする。ログラ
イトバッファの内容を実際にＩ／Ｏ出力するのはログラ
イトデーモン１０５と呼ぶデーモンの働きによる。
【０１８２】巨大トランザクションには、一般トランザ
クションが用いるログバッファよりも大きいログバッフ
ァ（以降、それぞれを一般ログバッファ、巨大ログバッ
ファと呼ぶ）を１つ用意する。巨大トランザクションも
当初は一般ログバッファの１つを用いる。巨大トランザ
クションとログバッファの関係には次の二段階がある。 １）あまり多くのメタデータを更新せず、一般ログバッ
ファで十分足りると判断できた時点で、次の巨大トラン
ザクションのＢＥＧＩＮを受け付ける。 ２）更新するメタデータ数がある程度多く、一般ログバ
ッファでは足りないと判断できた時点で、巨大ログバッ
ファにこれまでの内容をコピー、そこで処理を継続す
る。 ３）更新するメタデータ数が大変多く、巨大ログバッフ
ァでは足りない場合には、サブトランザクションとして
分割する。
【０１８３】２）におけるバッファ間のコピーが負担と
なりそうであるが、巨大トランザクションがそれほど多
くないと考えると、あまり頻繁に発生するものではない
ので、この方法とする。
【０１８４】一般ログバッファは状態（利用中・未利
用）について、ビットマップで管理される。各ログバッ
ファを管理する構造をログバッファ数の配列で確保し、
それぞれが ・ログバッファのアドレス ・これまでに採取したログサイズ を持っている。
【０１８５】また、ログバッファの内容は専用のログラ
イトデーモン１０５によってログボリューム１２０ヘ反
映するが、そのログライトデーモン１０５が複数のログ
バッファの内容を一括してＩ／Ｏ発行するために、トラ
ンザクション終了時にそれぞれのログバッファの内容を
ログライトバッファ１５０と呼ぶ専用の領域にコピーす
る。
【０１８６】ログライトバッファを管理する構造とし
て、 ・追加モードにあるログライトバッファはどちらか ・それぞれのログライトバッファに溜められたログサイ
ズ がある。
【０１８７】ログライトバッファの内容をログボリュー
ム１２０ヘ書き出している間は、その後のトランザクシ
ョンが終了するためにログライトバッファにログバッフ
ァをコピーしようとしても、Ｉ／Ｏ中であるためにガー
ドしなければならない。これは性能劣化に繋がるため避
けなければならない。そのため、ログライトバッファは
２本用意する。
【０１８８】一般トランザクションはトランザクション
開始時に、空のログバッファをビットマップより見つけ
（未利用ログバッファを０で示し、ここで１とする）、
そのビット番号がトランザクション番号となる。
【０１８９】巨大トランザクションが一般ログバッファ
にて処理進行中、一般ログバッファでは入りきらないと
判断されるとこれまでの内容をこの巨大ログバッファヘ
コピーし、そこで処理を継続する。この時、これまで用
いていた一般ログバッファは空きバッファリストヘ繋ぎ
直される。 （２．２）巨大トランザクションの管理 空き領域管理ツリーや獲得済領域管理ツリーを操作する
トランザクションを巨大トランザクションと定義する。
巨大トランザクションは場合によっては木構造を大きく
変更しなければならないかもしれない。この時、サブト
ランザクション化する必要が生ずる。
【０１９０】サブトランザクション化した巨大トランザ
クションが並行動作した場合、どれもが多くのメタデー
タを更新すると、メタキャッシュ１３０がいずれ全てダ
ーティとなり、新たにメタデータを読み込んで更新しよ
うにも追い出すこともできずにデッドロックに陥ること
が考えられる。
【０１９１】そのため、巨大トランザクションについて
は並行動作ができないよう、ここではシリアライズし
た。しかし、上記の通り、多くのメタデータを更新する
可能性があると考えられるトランザクションは多い。こ
れらを全てトランザクション終了までシリアライズする
と、その性能インパクトは大きい。
【０１９２】巨大トランザクションも、場合によっては
それほど多くのメタデータを更新しないこともありえ
る。一般トランザクションと同等の数しかメタデータを
更新しないのであれば、扱いを一般トランザクションと
同様にすることによって、その性能インパクトを小さく
することが可能である。
【０１９３】そこで、巨大トランザクションが一般トラ
ンザクションと変わらない程度しかメタデータを更新し
ないと分かった時点で、この巨大トランザクションの扱
いは一般トランザクションと同じにする（デグレー
ド）。
【０１９４】巨大トランザクションはその開始時には一
般ログバッファの１つを一般トランザクション開始時と
同様に与えられる。しかし、１つの巨大トランザクショ
ンが動作中は次の巨大トランザクションにログバッファ
を与えない点が一般トランザクションの場合と異なる。
【０１９５】巨大トランザクションがある程度以上のメ
タデータを更新することが分かった時点で、これまでの
一般ログバッファの内容を巨大ログバッファヘコピー
し、そこで処理を継続する。
【０１９６】しかし、それほど多くのメタデータを更新
しないと判断されれば、そのまま一般ログバッファで処
理が継続され、また、次の巨大トランザクションに対
し、処理の開始（ログバッファに使用）を許可する。
【０１９７】こうして、巨大トランザクションを途中か
ら一般トランザクションとして扱うこと（デグレード）
を実現する。 （２．２．１）デグレード契機・サブトランザクション
化契機 巨大トランザクションは複数のサブトランザクションに
分割される場合もあれば、一般トランザクションへデグ
レードする場合もある。それぞれの判定基準は以下の通
りである。 ◎デグレード判定基準 ・一般ログバッファの残りサイズで、将来全てのメタデ
ータ更新が完了できると判断できた場合。 ◎巨大トランザクション用ログバッファへの移行契機 ・一般ログバッファの残りサイズが次のステップの最大
変更量よりも少ない場合。 ◎サブトランザクション判定基準 ・巨大ログバッファの残りサイズが次ステップの最大変
更量よりも少ない場合。 （２．３）一般トランザクションのログ採取 一般トランザクションは、以下の手順に従いログを採取
する。 １）ＬＯＧ＿ＢＥＧＩＮ ａ）利用するログバッファを確定する。
【０１９８】ｂ）ログバッファの先頭にＢＥＧＩＮマー
クを作成する。 ２）各メタデータの更新 ｃ）更新されたメタデータがリリースされる（ロックが
解放される）直前に、更新されたメタデータについて、
ヘッダ（更新情報）をログバッファに作成し、更新内容
をログバッファにコピーする。
【０１９９】ｄ）更新されたメタデータをリストに繋
ぐ。 ３）ＬＯＧ＿ＥＮＤ ｅ）ＥＮＤマークをログバッファに作成する。
【０２００】ｆ）ログバッファをログライトバッファヘ
コピーする。 ｇ）ログライトデーモン１０５がログボリューム１２０
ヘ反映する。 ｈ）このトランザクションで立てられた追い出し不可フ
ラグを落とす。 （２．３．１）ＬＯＧ＿ＢＥＧＩＮ トランザクション開始を意味する。同一関数内にＬＯＧ
＿ＥＮＤの宣言が必要。並行動作可能数だけ既にトラン
ザクションが動作していたら、それらのどれか１つが終
了するまで寝て待つ。
【０２０１】ａ）現在実行中のトランザクション数がロ
グバッファの数と等しい場合、それは既に許された並行
動作数だけトランザクションが実行中であることを意味
する。そのため、他トランザクションが終了するまで寝
る。そのような状態でなければ、ログバッファの利用状
況を管理するビットマップより未利用状態のログバッフ
ァを１つ選び出し、そのビットを立てる。さらに、並行
動作数カウンタをインクリメントする。
【０２０２】ｂ）前述のＢＥＧＩＮマークをログバッフ
ァの先頭に作成する。 （２．３．２）各メタデータの更新 メタデータを参照した場合にはログ採取の必要はない。
更新した場合のみログを採らなければならない。
【０２０３】ｃ）メタキャッシュ１３０に読み込んだメ
タデータについて処理が終了し、メタキャッシュ１３０
より解放するための関数（リリース関数）を呼び出す
際、「更新した」ことを明示された場合、ログを採取す
る。
【０２０４】ｉノードについてはログ対象トランザクシ
ョン内でのロック解放時がログ採取契機でおる。具体的
には、上記で使用権を得たログバッファにヘッダを作成
し、メタデータの更新内容をコピーする。このとき、メ
タデータの種類によってその手法が若干異なる。
【０２０５】ｃ−１）ビットマップの場合：ヘッダには
獲得（解放）したメタデータ番号を入れ、更新内容は
「０→１」「１→０」とビット操作だけとする。 ｃ−２）メタデータ本体の場合：更新内容にはメタデー
タをそのままコピーする。
【０２０６】ｃ−３）スーパブロックの場合：巨大トラ
ンザクションがデグレードした場合のみ、一般ログ内で
のスーパブロックのログ採取がありうる。その時刻（シ
ーケンシャル番号）とデータ空きサイズを記録する。
【０２０７】コピーするとともに、ログバッファのター
ミナルで管理されるログサイズに、っこで作成したログ
のサイズを加える。 ｄ）メタキャッシュ１３０の大きさは有限であることか
ら、トランザクションが進行するためには、必要のない
メタデータをメタキャッシュ１３０から追い出し、その
場所に必要なメタデータを読み込むという処理を行う追
い出し機構がある。更新されたメタデータはログを書き
出すまでは追い出されてはならない。そのために、この
メタデータをメタライトリストと呼ぶ、メタボリューム
ヘの反映を司るメタライトデーモン１０４が参照するリ
ストへ繋ぐ。 （２．３．３）ＬＯＧ＿ＥＮＤ トランザクションの終了を示す。ここで、ＥＮＤマーク
の作成を行う。ログボリューム１２０反映はログライト
デーモン１０５による作業である。
【０２０８】ｅ）ＬＯＧ＿ＢＥＧＩＮにて作成したＢＥ
ＧＩＮマークに対応するＥＮＤマークをログバッファの
末尾に作成する。 ｆ）利用したログバッファの内容を追加モードにあるロ
グライトバッファにコピーする。この時にログ番号を決
定し、ＢＥＧＩＮマーク、ＥＮＤマークに埋め込むログ
バッファのターミナルに記録していたログのサイズをロ
グライトバッファのサイズに加える。同期書き込み要求
の場合は、ログライトデーモン１０５（詳細後述）が正
常にログボリューム１２０に反映したことを待つ必要が
あるが、同期書き込み要求でない場合には、ログバッフ
ァを解放（ビットを落とす）して終了する。
【０２０９】ｇ）後述するログライトデーモン１０５
が、ログライトバッファの内容をログボリュームヘ反映
する。 ｈ）リリース時に立てた追い出し不可フラグを全て落と
す。ただし、フラグを落とすのはログライドデーモンに
よってなされるため、このトランザクションはそのまま
終了する。 （２．４）巨大トランザクションのログ採取 巨大トランザクションも、一般トランザクションとほぼ
同様の処理だが、最大の違いは、トランザクションの状
況によってログバッファをサイズの大きい巨大ログバッ
ファヘ移行したり、サブトランザクションとして分割し
たログ採取を行わなければならない場合があることであ
る。 １）ＬＯＧ＿ＢＥＧＩＮ ａ）利用するログバッファを確定する。
【０２１０】ｂ）ログバッファの先頭にＢＥＧＩＮマー
クを作成する。 ｃ）ＢＥＧＩＮマーク作成と同時に、オペレーションロ
グをログバッファに作成する。 ２）各メタデータの更新 メタデータがリリースされた時に「更新したこと」が明
示されたら、 ｄ）更新メタデータが空き管理情報の場合、更新メタデ
ータがリリースされる度にＢＴＦリストあるいはＢＴＡ
リストとよぶ空き管理メタデータのために用意するリス
トに繋ぐ。この時、既にリストに繋がれていればリスト
構造には手を加えない。
【０２１１】ｅ）更新メタデータが空き管理情報以外の
場合、更新されたメタデータがリリースされる度にヘッ
ダをログバッファに作成し、更新内容をログバッファ域
にコピーする。
【０２１２】ｆ）更新メタデータをリストに繋ぐ。まだ
一般ログバッファで処理している場合、 ｇ）一般ログバッファで足りるか判定する ｇ−ａ）足りないなら巨大ログバッファヘこれまでの内
容をコピー。
【０２１３】ｇ−ｂ）足りると確定でき、かつ、デグレ
ード条件を満たせば、次の巨大トランザクションを受け
付ける。 ｇ−ｃ）まだ判断ができなければそのまま継続する。既
に巨大ログバッファで処理している場合、 ｈ）サブトランザクション化するか判定する ｈ−ａ）するなら、ＢＴＦリスト及びＢＴＡリストをた
どりながらそれらをログバッファにコピー、ＥＮＤマー
クを作成し、ログライトバッファヘコピーする。ログラ
イトデーモン１０５を起動し、ログを出力する。
【０２１４】ｈ−ｂ）まだしないなら、そのまま継続す
る。 ３）ＬＯＧ＿ＥＮＤ ｉ）最終ＥＮＤマークをログバッファに作成する。
【０２１５】ｊ）ログバッファをログライトバッファヘ
コピーする。 ｋ）ログライトデーモン１０５がログボリューム１２０
ヘ反映する。 ｌ）このトランザクションで立てられた追い出し不可フ
ラグを落とす。 （２．４．１）ＬＯＧ＿ＢＥＧＩＮ 巨大トランザクションも最初は一般ログバッファを用い
る。
【０２１６】ａ）一般トランザクションの場合は、現在
の並行動作トランザクション数とログバッファの数との
関係によってログバッファを獲得できるかどうかが定ま
った。巨大トランザクションの場合は、現在他の巨大ト
ランザクションが動作中か否かが問題であり、一般トラ
ンザクションの並行動作数とは関係しない。巨大トラン
ザクションが動作中か否かのフラグを調査し、非動作中
であれば、そのフラグを立て、ログバッファの利用状況
を管理するビットマップより未利用状態のログバッファ
を１つ選び出し、そのビットを立てる。巨大トランザク
ションが現在動作中であれば、終了まで寝て待つ。
【０２１７】ｂ）ＢＥＧＩＮマークを作成する。ここ
で、トランザクションタイプに巨大トランザクションと
なりうるトランザクションが指定されていた場合には、
必ず後ろにはオペレーションログが付随する。対応する
ＥＮＤマークがないログはリプレイしてはならない。ま
た、サブトランザクション化しているのに、最終ＥＮＤ
マークがないなら、オペレーションログのリプレイが必
要である。
【０２１８】ｃ）巨大トランザクションをサブトランザ
クションログとして分割する場合にはオペレーションロ
グを採取する必要がある。ここで、オペレーションログ
とは、各ログ採取対象関数に与えられたパラメタが、将
来リプレイすることが可能な形に変更されたものであ
る。具体的には、メモリアドレスで与えられるパラメタ
は、メタボリューム内のオフセットに変更して記録す
る。 （２．４．２）各メタデータの更新 ｄ）更新メタデータが空き管理情報である場合、一回の
トランザクションで同一の領域が何度も変更される場合
が考えられる。その都度、ログを採取しているとインコ
アログやログボリュームがフルになる可能性が高まる。
これを回避するために、更新情報をリストによって管理
し、複数回更新された空き管理メタデータを１つにまと
めてログに記録する。具体的には、メタデータの状態毎
にリスト管理する専用のＢＴＦリスト及びＢＴＡリスト
に繋がれる。このリストに繋がれていれば、そのデータ
はダーティであることを意味する。初めて更新するデー
タであれば、ターミナルから繋がるリストに追加する。
既にリストに繋がれているのであれば、２回目以降の更
新であることを意味し、ポインタについてはそのままで
良い。リストにメタデータを追加する場合には、ログサ
イズを更新する。
【０２１９】ｅ）更新メタデータが室き管理情報以外で
あれば、同一メタデータに対して何度もホールド／リリ
ースが発行されるとは考えられないので、リリースの度
（ロック解放の度）にログバッファヘコピーする（一般
トランザクションの場合と同じ）。ログサイズを更新す
る。
【０２２０】ｆ）既に何度か述べたが、更新されたメタ
データがログよりも先にメタボリューム１１１〜１１３
ヘ反映されてはならない。この追い出し不可状態もリス
ト構造によって管理される。
【０２２１】ｇ）この巨大トランザクションが更新する
メタデータが、以降、どれだけの数のメタデータを更新
するかを算出することによって、処理が分かれる。 ｇ−ａ）現在利用している一般ログバッファの残りでは
次ステップの実行によるメタデータの更新の全てをまか
ないきれない場合があると判断した場合には、巨大ログ
バッファヘの移管を行う。
【０２２２】ｇａ−１）これまでに溜まったログバッフ
ァの内容を巨大ログバッファヘコピーする。この時、Ｂ
ＴＦリストはそのまま繋いだままとし、ＢＴＡリストは
巨大トランザクション用のターミナルヘ移動する。
【０２２３】ｇａ−２）巨大ログバッファを利用して、
その巨大トランザクションは処理を継続する。 ｇ−ｂ）現在利用している一般ログバッファの残りだけ
で、以降のメタデータ更新を全て記録できると判断でき
るならば、この巨大トランザクションは一般トランザク
ションにデグレードする。ＢＴＦリストにメタデータが
繋がれている場合はデグレード条件を満たさないため、
ここでの処理はありえない。ＢＴＦリストはそのまま利
用を続ける。
【０２２４】ｇｂ−１）巨大トランザクションが動作中
か否かを示すフラグを落とす。 ｇｂ−２）一般トランザクションの並行動作数カウンタ
をインクリメント。 ｇｂ−３）次の巨大トランザクションが寝ているならば
起こして、実行を受け付ける。
【０２２５】ｇｂ−４）このまま一般ログバッファを利
用して処理を継続する。 ｇ−ｃ）まだ判断できないのであれば、このまま一般ロ
グバッファを利用して処理を継続する。
【０２２６】ｈ）サブトランザクション判定基準（前
述）に基づき、このトランザクションをサブトランザク
ション化するかどうか判定する。 ｈ−ａ）サブトランザクションに分割する場合は、 ｈａ−１）更新された空き管理情報を、リストを辿りな
がらログバッファヘコピーする。
【０２２７】ｈａ−２）ＥＮＤマークを作成する。 ｈａ−３）ログライトバッファヘコピーする。 ｈａ−４）ログライトサイズを更新する。
【０２２８】ｈａ−５）ログライトデーモン１０５を強
制起動する。 ｈａ−６）ここで変更した全てのメタデータの追い出し
不可フラグを落としてメタライトリストに繋ぐ。これに
より，メタライトデーモン１０４は任意の時ににこれら
のメタデータを書き出すことが可能となる。
【０２２９】ｈａ−７）巨大ログバッファの先頭にＢＥ
ＧＩＮマークを作成する。 ｈａ−８）オペレーションログを作成する。 ｈ−ｂ）サブトランザクションに分割する必要がない間
は、巨大ログバッファ内でそのまま継続する。 （２．４．３）ＬＯＧ＿ＥＮＤ トランザクションの終了を示す。ここで、ＥＮＤマーク
の作成を行う。実際のログボリューム１２０反映はログ
ライトデーモン１０５の仕事である。
【０２３０】ｉ）最終ＥＮＤマークを作成する。最終Ｅ
ＮＤマークは通常のＥＮＤマークとマジックワードが異
なるだけである。 ｊ）利用したログバッファの内容を追加モードにあるロ
グライトバッファヘコピーする。この時にログ番号を決
定し、ログサイズをログライトサイズに加える。同期書
き込み要求の場合は、ログライトデーモン１０５が正常
にログボリューム１２０反映したことを待つ必要がある
が、その他の場合には待たないで次の処理へ進む（すな
わち非同期書き出しである）。巨大トランザクション動
作中フラグを落とし、寝て待つ次の巨大トランザクショ
ンを起こす。
【０２３１】ｋ）ログライトデーモン１０５が、ログラ
イトバッファの内容をログボリュームヘ反映する。 ｌ）更新したメタデータをログバッファヘコピーした時
に立てた追い出し不可フラグを全て落とす。ただし、フ
ラグを落とすのはログライトデーモン１０５によってな
されるため、このトランザクションはそのまま終了す
る。 （２．５）ログライトデーモン 並行して動作し、順次終了するトランザクションによっ
て更新されたメタデータのログは専用の書き出しデーモ
ン（ログライトデーモン１０５）によってログボリュー
ムヘ反映する。このデーモンはマウント時に起動され、
アンマウント時に停止する。すなわち、ファイルシステ
ム毎にスレッドを生成する。
【０２３２】各トランザクションが終了すると、ログバ
ッファ内にＥＮＤマークが作成され、このログバッファ
の内容はログライトバッファ１５０にコピーされる。こ
のログライトバッファ１５０は複数のログバッファの内
容を一括してログボリューム１２０に反映するためのも
のであり、そこにはメモリコピーの負担があるが、何度
もＩ／Ｏを発行するよりは良いと考える。
【０２３３】ログライトバッファ１５０ヘコピーされる
と、そのログバッファは利用中バッファリストから空き
バッファリストヘと繋ぎ直され、かつ、トランザクショ
ンが同期書き込み要求でなければ、動作中トランザクシ
ョン数をデクリメントする。これにより、次トランザク
ションの実行が進むようになる。
【０２３４】ログライトデーモン１０５はログライトバ
ッファの内容を、定期的、あるいは同期書き込み指定の
トランザクションがある場合などにログボリュームに反
映する。反映している間（Ｉ／Ｏ中）は２本あるログラ
イトバッファのうち、もう片方のログライトバッファに
内容をコピーしてそのトランザクションは処理を終了す
る。 （２．５．１）処理手順 ログライトデーモン１０５単体の処理手順はそれほど複
雑ではない。
【０２３５】ａ）現在のログライトバッファをライトモ
ードにし、もう片方を追加モードにする。 ｂ）ログライトバッファの内容をログボリューム１２０
ヘ同期書き出しする。
【０２３６】ｏ）場合に応じて有効範囲情報を書き出
す。 ｄ）ログ待ちリストに繋がるメタデータを、メタライト
リストヘ繋ぎかえる。 ｅ）規定時間の間、スリープする。
【０２３７】ｆ）規定時問が経過、または他の要因で起
こされたらａ）へ。 以下、詳細説明である。 ａ）Ｉ／Ｏ中はその対象域に対して追加更新は許されな
い。そのため、現在のログライトバッファが書き出しが
終わり、次の書き出しが始まるまでは、もう片方のログ
ライトバッファヘ終了したログバッファをコピーするよ
う設定する。Ｉ／Ｏ中のログライトバッファをライトモ
ード、ログバッファの内容をコピーする方を追加モード
と呼ぶ。切り替えはこのデーモンによって行われ、各ト
ランザクションは常に追加モードにあるログライトバッ
ファに自ログバッファの内容をコピーする。
【０２３８】ｂ）ログライトバッファに新しい内容が含
まれていないのであれば、Ｉ／Ｏを発行する必要はな
い。そこで、まずログライトサイズを調べ、ゼロであれ
ばＩ／Ｏを発行せず、タイマを指定して再び寝る。書き
出すべきログが存在するのであれば、以下の手順に従
う。
【０２３９】ｂ−ａ）ログボリュームの空きサイズ判
定。 ログボリュームの先頭オフセット（Ａ）、メタライトリ
スト先頭のメタデータを管理する構造の上書き可能オフ
セット（Ｂ）を調べる。それとログライトオフセット
（Ｃ）、及びログボリュームの最終オフセット（Ｄ）か
ら以下の手順となる。 ・Ａ＜Ｂ≦Ｃ＜Ｄ ログライトサイズが（Ｄ−Ｃ）以下ならば、Ｃから書
き出す。 ログライトサイズが（Ｄ−Ｃ）より大きく、かつ、
（Ｂ−Ａ）以下ならば、Ａから書き出す。 ・Ａ≦Ｃ＜Ｂ≦Ｄ ログライトサイズが（Ｂ−Ｃ）より小さければ、Ｃか
ら書き出す。
【０２４０】これらの条件に合致せず、ログの出力がで
きない場合には、メタライトデーモン１０４を起動し
て、自分はスリープする。メタライトデーモン１０４の
動作により起動されたら、再度、空きサイズ判定から行
う。
【０２４１】ｂ−ｂ）ログボリューム１２０ヘ同期書き
出しする。 ｂ−ｃ）エラー判定。同期書き出し後、エラー判定を行
う。エラーが発見された場合の処置については後述
（２．５．３）する。
【０２４２】ｂ−ｄ）領域判定。 書き出しが終わった後、再び、ｂ−ａ）と同様な空き領
域の判定を行う。ここで、残りが少ないと判定された
時、その残りの大きさに応じてメタライトデーモン１０
４を「平常起動」「緊急起動」する。
【０２４３】ｃ）ファイルシステム復元に必要なログ
は、メタライトリスト先頭の上書き可能オフセットから
たった今書き出した位置までである。そこで、それを有
効範囲情報としてディスクヘ書き出す。ここで、書き出
しはログのシーケンシャル性を考慮し、ある程度の間隔
をおいて行う。ここでは、回数に応じて、数回に一回、
書き出すこととした。
【０２４４】ｄ）ｂ）にて書き出したログに含まれるメ
タデータは全て「ログ未反映状態」、すなわち追い出し
不可状態としてリスト（ログ未反映リスト）に繋がれて
いるはずである。そこで、ログ未反映リストを辿りなが
ら、そこに繋がるメタデータをメタライトリストに追加
することにより、メタライトデーモン１０４が任意の時
にこれらのメタデータをメタボリュームに反映できるよ
うになる。
【０２４５】ｅ）ログもシステム全体から見れば非同期
書き出しとし、トランザクションが同期書き込み要求で
なければ、ログを書き出す前にそのトランザクションは
終了することができる。さらにＩ／Ｏ発行回数を削減す
るために、複数のトランザクションを一括して書き出す
ために、しばらくの間スリープし、その間にログライト
バッファヘ複数トランザクションのログを溜める。
【０２４６】ｆ）規定時間後には自分で起きて、処理を
繰り返す。しかし、他要因によって突然起こされて処理
を始める場合もある。「その他の要因については後述
（２．５．２）する。 （２．５．２）動作契機 ログライトデーモン１０５は以下の契機でログライトバ
ッファの内容をログボリュームへ書き出す。 ◎定周期 ログライトデーモン１０５は一定周期毎にスリープ状態
から自発的に目覚め、ログライトバッファ１５０の内容
をログボリューム１２０ヘ反映する。 ◎同期書き込み要求のトランザクション トランザクションによっては同期書き込み要求で呼ばれ
る場合がある。このトランザクションについては、ログ
の書き出しを待たなければ終了してはならない。そのた
め、ＬＯＧ＿ＥＮＤ呼び出し後に、明示的にＬＯＧ＿Ｓ
ＹＮＣを行う。ＬＯＧ＿ＳＹＮＣはログライトデーモン
１０５が寝ている場合には起こし、ログライトバッファ
の内容をその場で書き出させる。
【０２４７】現在ログライトデーモン１０５がＩ／Ｏ中
であったら、ログライトデーモン１０５の処理が終わる
のを寝て待つ。 ◎ログライトバッファ不足定 周期毎にログライトバッファをクリアしても、大きなロ
グバッファが連続して終了すると、その前にログライト
バッファがフルに近い状態になることがありえる。この
時にはログライトデーモン１０５が起こされ、ログライ
トバッファ１５０の内容をログボリューム１２０に書き
出してクリアする。
【０２４８】具体的には、あるトランザクションが自ロ
グバッファの内容をＬＯＧ＿ＥＮＤによってコピーしよ
うとした時、ログライトバッファ１５０の残りサイズが
自ログよりも小さいと判断された時、ログライトデーモ
ン１０５を起こし、追加モードのログライトバッファ１
５０を切り替えてもらい、その間は寝て待つ。
【０２４９】現在Ｉ／Ｏ中てあり、かつ追加モードのロ
グライトバッファ１５０が足りなくなった時には、その
トランザクションは待ち合わさざるを得ない。 ◎メタキャッシュ不足 トランザクション実行中に、メタキャッシュ１３０域の
いずれかのメタデータを追い出さなければ必要なメタデ
ータをメタボリューム１１１〜１１３から読み込むこと
ができずに処理が進まなくなる場合が考えられる。
【０２５０】そのため、トランザクションが現在キャッ
シュ上のメタデータを追い出そうとする時、メタキャッ
シュ１３０上のメタデータが全てダーティであり、か
つ、ログ待ちリストに繋がれたメタデータが存在する場
合には、ログライトデーモン１０５を起動する。 ◎アンマウント時 アンマウント時には必ず書き出さなければならない。そ
のため、アンマウント処理の延長でログライトデーモン
１０５を起こし、書き出しを行う。この時、アンマウン
トを実行するため、該当ファイルシステムにメタデータ
を更新するようなトランザクションは動作していないこ
とが保証される。従って、現在のログライトバッファの
内容を者き出せば、それで全てである。
【０２５１】ログリアとバッファの内容を書き出した
後、ログライトデーモン１０５は終了する。 （３）メタデータ管理 次に、メタデータの管理方式について説明する。メタキ
ャッシュ１３０内のメタデータはｍｅｔａｌｉｓｔ構造
体によって管理される。ｍｅｔａｌｉｓｔ構造体には以
下のメンバがある。 ・メタデータへのポインタ ・ＴＲＡＮＳ（トランザクション）リストポインタ ・メタライトリストｐｒｅｖボインタ ・メタライトリストｎｅｘｔポインタ ・ログ待ちリストｐｒｅｖポインタ ・ログ待ちリストｎｅｘｔポインタ ・ログシーケンス番号 ・ログボリューム内オフセット ・トランザクション番号 ・状態フラグ ・メタデータタイプ ・ｂｕｆ構造体実体 （３．１）メタデータの状態遷移 ｍｅｔａｌｉｓｔ構造体には次の６種類の状態があり、
４種類のリストに繋がれる。それはｍｅｔａｌｉｓｔ構
造体のフラグによって示され、それぞれ夕ーミナルを別
とするリストに繋げられることによって実現する。全て
のｍｅｔａｌｉｓｔ構造体はいずれかのリストに繋がっ
ており、例外はない。 Ａ）空き管理構造更新状態 データ空き領域を管理するメタデータがトランザクショ
ンによって更新されると、リストに繋ぎ、将来まとめて
ログバッファにコピーすることは既に述べた。トランザ
クション終了時に本リストに繋がれたメタデータが直接
ログボリュームヘ反映される。リストは並行動作数に応
じて必要である。このリストをＢＴＦリストと呼ぶ。
【０２５２】この状態にあるメタデータはまだログバッ
ファヘはコピーされておらず、同一トランザクションに
よって再度更新される場合がある。既にリストに繋がれ
ているメタデータであった場合は、リスト状態は変更し
ない。当然、メタボリュームに反映してはならない。
【０２５３】ＢＴＦリストは単方向環状リストであり、
トランザクション途中状態と同じメンバを用いて繋がれ
ている。 Ｂ）利用域管理構造更新状態 実施例ではファイルシステムをエクステント管理してい
る。ｉノードから導かれる、そのファイルが利用してい
るエクステントを示す、間接エクステントブロックにつ
いても、トランザクション内で１つの間接エクステント
ブロックが何度も更新される場合が考えられる。そこ
で、空き管理構造の場合と同様に、トランザクション中
は独自のリストに繋ぎ、トランザクション終了時にまと
めてログバッファヘコピーする。リストは並行動作数に
応じて必要である。このリストをＢＴＡリストと呼ぶ。
【０２５４】この状態にある間接エクステントブロック
はまだログバッファヘはコピーされておらず、同一トラ
ンザクションによって再度更新される場合がある。既に
リストに繋がれている間接エクステントブロックであっ
た場合は、リスト状態は変更しない。当然、メタボリュ
ームに反映してはならない。
【０２５５】ＢＴＡリストは単方向環状リストであり、
トランザクション途中状態と同じメンバを用いて繋がれ
ている。 Ｃ）トランザクション途中状態 トランザクション途中を示す。この状態のとき、該当す
るメタデータを更新したトランザクションは、ある１つ
のログバッファを専有しており、既にそこに更新後状態
がコピーされている。リストは並行動作数に応じて必要
である。このリストをＴＲＡＮＳリストと呼ぶ。
【０２５６】しかし、まだトランザクションが終了して
いないことからログがログボリューム１２０ヘ反映され
ておらず、本メタデータもメタボリュームヘの反映はで
きない。この状態にあるメタデータはファイルのロック
によって保護されているため、他トランザクションから
参照・更新されることはない。
【０２５７】ＴＲＡＮＳリストのターミナルは配列にな
っており、その要素番号はトランザクションが用いてい
るログバッファの番号（トランザクション番号）に対応
する。
【０２５８】メタライトリストやログ待ちリストに繋が
れているメタデータが繋がる場合がある。ＴＲＡＮＳリ
ストは単方向環状リストであり、ＢＴＦリストが用いる
メンバを併用する。
【０２５９】Ｄ）ログ待ち状態 トランザクションは既に終了しているが、ログバッファ
の内容はログライトデーモン１０５によってログボリュ
ーム１２０ヘ反映されるため、この時点ではまだログボ
リューム１２０に反映されていない状態である。（デー
モンは同期ライトを行うが、トランザクションの視点か
ら見れば、ログ反映が非同期に行われているように見え
る。） トランザクションが終了する際に、Ｃ）の状態にあるＴ
ＲＡＮＳリスト（巨大トランザクションの場合はＢＴＦ
リストも）をログ待ちリストに繋ぎかえる。このリスト
はトランザクションが終了する毎に後方へ伸びるリスト
であり、ログライトバッファと同数の２本存在する。
【０２６０】この状態にあるメタデータは既にトランザ
クションが終了しており、ログはログライトバッファに
コピーされている。トランザクションが終了しているこ
とから、他トランザクションによって参照・更新される
可能性がある。この時（他トランザクションによって状
態が変化した時）、リスト位置は変更せず、状態フラグ
だけを変更する。
【０２６１】メタライトリストに繋がれたメタデータ
が、他トランザクションによって再度更新されたため
に、トランザクション途中状態になり、そのトランザク
ションが終了したことによって、ログ待ち状態になった
場合には、このメタデータはメタライトリストにも繋が
れている。
【０２６２】ログライトデーモン１０５によって、ログ
の反映が進むと、それに応じたメタデータをメタライト
リストヘ追加していく。この時、既にメタライトリスト
に繋がれているメタデータは、そのままの位置でいなけ
ればならない。 Ｅ）書き出し可能状態 これは、ログバッファのログボリュームへ反映が終了
し、自由にメタデータをメタボリュームへ反映すること
ができるようになった状態である。この状態にあるメタ
データは他トランザクションによって参照・更新される
可能性がある。この時、リスト位置は変更せず、状態フ
ラグだけを変更する。
【０２６３】繋がるリストはメタライトリストであり、
１本だけ存在する。メタライトデーモン１０４はこのリ
ストを参照してメタボリュームヘの反映を行う。 Ｆ）Ｉ／Ｏ中状態 この状態にあるメタデータは現在非同期ライトによって
メタボリュームに対してＩ／Ｏを投げているが、まだ完
了していない。Ｉ／Ｏ途中であるため、他トランザクシ
ョンは操作することができない（参照することはでき
る）。メタライトリストにそのまま繋がれている。 （３−２）ログボリュームの上書き判定情報 ログボリュームはサイズが有限であるため、サイクリッ
クに利用し、過去のログを上書きしてシステムは動作す
る。ここで、過去のログを上書きするためには、そのト
ランザクションが更新したメタデータが全てメタボリュ
ームに反映されていることが必要である。上書き可能領
域を管理するために、以下の構造を設け、メタライトデ
ーモン１０４が変更、ログライトデーモン１０５が参照
する。 ◎ログシーケンス番号 各トランザクションが終了し、ログバッファの内容をロ
グライトバッファヘコピーする毎に与えられる、シーケ
ンシャル番号である。ログボリューム内のＢＥＧＩＮマ
ーク、ＥＮＤマークに含まれる番号と同一である。既に
ライトリストに繋がるメタデータが再度更新される場合
にも、この番号は変更されない。 ◎ロクボリューム内オフセット ログボリューム内にはトランザクション毎のログが連続
して並んでおり、上書きするためには、それぞれのトラ
ンザクションが更新した全てのメタデータがメタボリュ
ームへ反映されている必要がある。
【０２６４】同一のログ番号を持つｍｅｔａｌｉｓｔ構
造体は、ここにはそのログの先頭オフセットを挿入す
る。ＬＯＧ＿ＥＮＤによってログバッファの内容がログ
ライトバッファにコピーされる際、そのアドレスとログ
ボリュームの書き出しオフセットから導かれる。トラン
ザクション毎のログボリューム内オフセットがＴＲＡＮ
Ｓリストを辿りながらそれぞれのｍｅｔａｌｉｓｔ構造
体に設定する。
【０２６５】ログライトデーモン１０５は、ログを書き
出す際にメタライトリストの先頭に繋がるｍｅｔａｌｉ
ｓｔ構造体を参照し、現在のポインタにログライトバッ
ファに入っているログサイズを足した位置が、このオフ
セット値を超えないことを確認した後で書き出しを行
う。 （３．３）メタボリュームヘの反映 トランザクションによって更新されたメタデータは、ト
ランザクションが終了しログがログボリューム１２０に
反映されるまでは書き出されてはならない。そのため
に、メタキャッシュ１３０上の各メタデータはそれぞれ
の状態に応じてリストに繋がれ、唯一メタボリュームヘ
の反映が許可されているリストはメタライトリストであ
る。
【０２６６】時間のかかるＩ／Ｏ要求をトランザクショ
ン内で行うことを避けるために、メタデータのメタボリ
ュームヘの反映はトランザクションとは関係ないところ
で動作するデーモンに委ねる。このデーモンはメタライ
トリストだけを意識し、ｍｅｔａｌｉｓｔ構造体内の情
報から状態に応じてＩ／Ｏ発行するかどうかを決定し、
関連付けられたｂｕｆ構造体を用いてメタデータをメタ
ボリュームヘ反映する。
【０２６７】デーモンはメタライトリストに繋がれたメ
タデータを書き出した後、そのメタデータをリストから
外し、ｃｌｅａｎであると設定する。 （３．４）メタライトデーモン メタライトデーモン１０４は、マウント時に起動され、
アンマウント時に停止する。すなわち、ファイルシステ
ム毎にスレッドを起動する。
【０２６８】ログ書き出しの終わったトランザクション
が更新したメタデータは、それを管理するｍｅｔａｌｉ
ｓｔ構造体が全てメタライトリストに繋がれている。メ
タライトデーモン１０４はメタライトリストに繋がるメ
タデータを、ログボリュームの残りが少なくなったと判
断された場合などに非同期でメタボリュームに反映す
る。反映している間は該当するメタデータは更新するこ
とができず、Ｉ／Ｏ終了を待ち合わせることになる。
【０２６９】メタライトデーモン１０４はメタライトリ
ストを意識し、繋がるメタデータをメタボリュームへ反
映する。これにより、ログボリュームの上書き可能領域
が拡大する。
【０２７０】しかし、メタライトリストに繋がれている
メタデータの中にも、再度トランザクションによって更
新が進み、メタボリュームヘの反映が禁じられているも
のが存在する場合がある。この時、他のメタデータを書
き出すとしても、そのメタデータについては非同期ライ
トの発行を待ちあわせなければならない。このようなメ
タデータが存在すると、以降のメタデータを全て書き出
せたとしても、上書き可能領域を拡大することができな
い。
【０２７１】メタライトデーモン１０４は他者から起動
されて処理を開始する場合と、自発的に起動する場合が
ある。以下に処理手順を述べるが、システムの状態（ロ
グボリュームの空きやメタキャッシュ１３０の空きな
ど）に応じて動作が若干異なる。また、ここで述べる処
理手順にはデーモン内だけではなく、ドライバから呼ば
れる関数での処理も含まれている。 （３．４．１）自発起動処理 メタライトデーモン１０４はタイマによって自発的に起
動して、それまでにメタライトシストに繋がれた書き出
し可能なメタデータをメタボリュームに反映する。この
時、メタライトリストの全てを書き出す訳ではなく、あ
る一定の数だけ非同期書き出しを行う。普段から少しず
つメタデータの書き出しを行っておくことによって、資
源不足による起動を避け、Ｉ／Ｏ負荷分散を図る目的が
ある。
【０２７２】ａ）自発起動時には、メタライトリストに
繋がるメタデータ数を調査する。 ｂ）メタライトリストの先頭から、メタデータの状態を
調べる。 ｃ）メタデータが書き出し可能状態であれば、その状態
をＩ／Ｏ負荷態に変更し、非同期ライトを発行する。
【０２７３】ｄ）ｂ＿ｉｏｄｏｎｅの関数がＩ／Ｏの成
功を確認する。 ｅ）ｂ＿ｉｏｄｏｎｅの関数がメタライトリストから外
す。 ｆ）規定数だけ繰り返す ｇ）スリープする。
【０２７４】以下、詳細説明である。 ａ）自発起動間隔として定義する間隔毎にメタライトリ
ストに繋がるメタデータ数を確認する。具体的には、メ
タライトリストのターミナルに含まれる、リンクされた
メタデータ数を調べる。このとき、それほど多くのメタ
データが繋がれていない場合には書き出しは行わない。
【０２７５】ｂ）メタライトリストには基本的にはログ
の書き出しが終わった、書き出し可能状態のメタデータ
が繋がれている。しかし、トランザクションが終了して
メタライトリストに繋がれた後で他トランザクションに
よって更新されると、そのメタデータだけは書き出し不
可の状態に戻ってしまう。そのため、メタライトデーモ
ン１０４はメタライトリストに繋がるメタデータの状態
を確認しながら書き出し処理を行わなければならない。
【０２７６】ｃ）現在ポイントするメタデータが書き出
し可能状態であれば、その状態をＩ／Ｏ状態に書き換
え、ｍｅｔａｌｉｓｔ構造体に含まれるｂｕｆ構造体を
用いてＩ／Ｏを発行する。Ｉ／Ｏ中状態のメタデータは
他トランザクションから更新されることはない。メタデ
ータのディスクライトは非同期ライトで行い、デーモン
はＩ／Ｏの結果を待たずに次の処理へ進む。
【０２７７】メタデータが書き出し不可状態であるな
ら、そのメタデータは諦め、リストの次に繋がるメタデ
ータに進み、状態を調べる。 ｄ）非同期ライトによって発行されたＩ／Ｏの結果を判
定するのは、ｂｕｆ構造体のメンバｂ＿ｉｏｄｏｎｅに
組み込まれた関数である。この関数にはｂｕｆ構造体が
引数に与えられ、それを元にエラー判定処理を呼び出
す。ここでエラーを検出した場合には、異常系処理へ進
む（後述）。成功していた場合には、該当メタデータの
ｃｌｅａｎ数をインクリメントする。
【０２７８】ｅ）ｂ＿ｉｏｄｏｎｅに組み込まれた関数
はメタライトリストの管理も行う。引数に渡されたｂｕ
ｆ構造体の上を見るとそこはｍｅｔａｌｉｓｔ構造体に
なっており、そのフフグからＩ／Ｏ中フラグを落とし、
メタライトリストから外す。また、メタデータをダーテ
ィ状態からｃｌｅａｎ状態へ変更する。これは、メタキ
ャッシュ１３０で管理されるメタデータである場合に
は、それぞれの管理構造体で管理されており、この管理
構造体はｍｅｔａｌｉｓｔ構造体からポイントされる。
【０２７９】全ての処理が終了したら、このｍｅｔａｌ
ｉｓｔ構造体をリリースする。 ｆ）メタライトリストに繋がる書き出し可能メタデータ
を、次々とリストを辿りながら定義した数だけ処理を繰
り返す。ここで、書き出しが不可とされているメタデー
タについては、この数には含めない。また、メタライト
リストが定義数よりも少ない場合には、当然そこで終了
となる。 ｇ）スリープする。再度、自発的に起動するか、あるい
は資源不足によって他から起動されるまで、スリープは
継続する。 （３．４．２）平常処理 システム状態が以下の場合には、ここで述べる処理手順
に従いメタライトデーモン１０４は動作する。 ◎ログボリュームの残りが少ない。
【０２８０】ログライトデーモン１０５が判断する。ロ
グライトバッファを書き出す際に、上書き可能域の大き
さを計算し、この閾値を下回った時にメタライトデーモ
ン１０４を起動する。 ◎メタキャッシュの残りが少ない。
【０２８１】更新リリースがあった時、各メタデータの
ｃｌｅａｎ数がデクリメントされるが、その数がこの閾
値を下回った時にメタライトデーモン１０４を起動す
る。 ａ）メタライトリストの先頭から、メタデータの状態を
調べる。
【０２８２】ｂ）メタデータが書き出し可能状態であれ
ば、その状態をＩ／Ｏ中状態に変更し、非同期ライトを
発行する。 ｃ）ｂ＿ｉｏｄｏｎｅの関数がＩ／Ｏの成功を確認す
る。
【０２８３】ｄ）ｂ＿ｉｏｄｏｎｅの関数がメタライト
リストから外す。 ｅ）メタライトリストの最後まで繰り返す。 ｆ）スリープする。
【０２８４】以下、詳細説明である。 ａ）〜ｄ）自発的に起動した場合と同じである。 ｅ）メタライトリストを辿りながら、繋がる全ての書き
出し可能メタデータについて処理を繰り返す。平常処理
時には、書き出し不可のメタデータについては飛ばして
処理を行う。そのため、ログボリューム不足時には、メ
タライトリストの先頭、すなわち、ログボリュームの上
書き可能位置を制限しているメタデータが書き出せなけ
れば資源不足は解消しないが、平常処理であるため、こ
こでは特別な対処を行わない。
【０２８５】ｆ）タイマを設定してスリープする。 （３．４．３）緊急処理 システム状態が以下の場合には、ここで述べる処理手順
に従いメタライトデーモン１０４は動作する。 ◎ログボリュームの残りが非常に少ない。 ◎メタキャッシュ１３０の残りが非常に少ない。
【０２８６】ａ）トランザクションの新規開始を制限す
る。 ｂ）メタライトリストの先頭から、メタデータの状態を
調べる。 ｃ）メタデータが書き出し可能状態であれば、その状態
をＩ／Ｏ中状態に変更し、非同期ライトを発行する。
【０２８７】ｄ）ログ未反映状態となっているメタデー
タがあれば、ログライトデーモン１０５を起動する。 ｅ）ｂ＿ｉｏｄｏｎｅの関数がＩ／Ｏの成功を確認す
る。
【０２８８】ｆ）ｂ＿ｉｏｄｏｎｅの関数がメタライト
リストから外す。 ｇ）繰り返す。 ｈ）現在の資源状態を調査し、不足があれば、それが解
消するまで繰り返す。
【０２８９】ｉ）トランザクションの受付を開始する。 ｊ）スリープする。 以下、詳細説明である。
【０２９０】ａ）緊急時には、新規のトランザクション
の開始を受け付けない。具体的には、トランザクション
に利用するログバッファを与えないことによって、その
トランザクションのＢＥＧＩＮ宣言時にてスリープさせ
る。そのために、特定のフラグを設け、ＢＥＧＩＮ宣言
時にそのフラグを参照しなければならない。
【０２９１】ｂ）〜ｇ）ここは基本的に平常処理の場合
と同じ処理である。すなわち、メタライトリストの先頭
から、追い出し不可状態のメタデータは飛ばして、書き
出し可能状態のメタデータを順に非同期ライトによって
書き出す。
【０２９２】ただし、ｄ）だけ異なる。 ｄ）ログボリュームヘの書き出しがデーモンによって行
われることから、たとえトランザクションが終了してい
てもログが未反映のためにメタボリュームへの反映を拒
否しているメタデータが存在することが考えられる。こ
の場合は、強制的にログライトデーモン１０５を起動し
て、書き出し可能状態へ移行するように操作する。既に
ログライトデーモン１０５が動作中であれば、そのまま
先へ進む。
【０２９３】ｈ）ここで、現在の資源状態を調べる。平
常処理の動作契機となる閾値以上の資源が回復していな
ければ、再度、メタライトリスト内のメタデータ書き出
しを試みる。ここで、ｄ）によってログ未反映状態のメ
タデータが、書き出し可能となったことによって進展す
ることを期待している。複数回、繰り返すことによっ
て、新規トランザクションの受付を制限していることか
ら、資源回復までメタデータの書き出しが可能であると
考える。
【０２９４】ｉ）ａ）にて制限していたトランザクショ
ンの受付を再開する。 ｊ）タイマを設定して、スリープする。 （４）獲得解放処理 メタデータの割り当て状況を管理するビットマップの状
態として、FREE-dirtyとALLOC-dirtyを区分し、FREE-di
rtyなビットマップからは獲得しないようにする。
【０２９５】具体的には以下の通りである。 ・マウント時にビットマップを読み込む際に、１つを獲
得用と定める。簡単のため、複数読み込むビットマップ
のうち、一番若いもの（最初に読み込むもの）を最初の
獲得用ビットマップとする。 ・獲得用ビットマップの複製を作成する。 ・獲得時には複製を検索して獲得位置を決定し、本体と
複製の両方のビットを操作する。 ・解放時には本体のみのビットを操作する。 ・複製ビットマップには解放が記録されないため、獲得
処理が進むと全てのビットが立ち、そのビットマップで
は獲得できないと判断される。その場合、現在メモリ上
にあるビットマップのうち、ＣＬＥＡＮなもの、または
ALLOC-dirtyのビットマップを次の獲得用ビットマップ
と定義し、その複製を作成する。 ・メモリ上のビットマップが全てFREE-dirtyである場合
には、どれかを追い出し、新しいビットマップを獲得用
ビットマップとして読み込む。そして、その複製を作成
する。ここで、追い出し・読み込みのアルゴリズムは従
来通りで良い。
【０２９６】獲得用ビットマップとして選ばれたビット
マップは追い出しの対象とはしない。そのためメタキャ
ッシュ域不足によって他から追い出されることはない。
また、メタライトリストに繋がったことによって、メタ
ボリュームに反映された場合にも、ＣＬＥＡＮな状態に
はなるが、複製は更新せず、そのままとする。
【０２９７】本実施の形態による効果は、以下の通りで
ある。以上説明したように、本発明によれば複数の二次
記憶装置に保存されたメタデータのログにボリューム情
報を含め、また、有効なログの位置を算出・保存するこ
とでリプレイするログ量を減少せしめ、さらに、ログボ
リューム全体のゼロクリアをする必要をなくすことによ
り、ログ機構の最大の利点であるところのファイルシス
テム復元時間の短縮に及ぼす影響を小さくし、オーバオ
ールコンピュータシステム可用性の増大に寄与するとこ
ろが大きい。
【０２９８】さらに、本発明によれば回一トランザクシ
ョン内で複数回更新されるメタデータのログを一度しか
採取せず、また、ログバッファの分割や、獲得・解放処
理の特殊なログ採取方式によって複数のトランザクショ
ンの独立性を考慮し、かつ、ログ機構導入による速度性
能の劣化を最小に留めることにおいて寄与するところが
大きい。
【０２９９】加えて、本発明によればトランザクション
毎に異なるログの採取量を考慮し、多くのメタデータを
更新するトランザクションについては分割し、トランザ
クションに与えられたパラメタをもログに採取し、リプ
レイ時にそのパラメタを元に、中途で終わったトランザ
クションを再度実行することによって、オペレーション
のセマンティクスを保証した復元が可能となる面におい
て寄与するところが大きい。
【０３００】なお、上記の処理機能は、コンピュータに
よって実現することができる。その場合、説明した処理
内容は、コンピュータで読み取り可能な記録媒体に記録
されたプログラムに記述されており、このプログラムを
コンピュータで実行することにより、上記処理がコンピ
ュータで実現される。コンピュータで読み取り可能な記
録媒体としては、磁気記録装置や半導体メモリ等があ
る。市場へ流通させる場合には、ＣＤ−ＲＯＭ(Compact
Disk Read Only Memory)やフロッピーディスク等の可
搬型記録媒体にプログラムを格納して流通させたり、ネ
ットワークを介して接続されたコンピュータの記憶装置
に格納しておき、ネットワークを通じて他のコンピュー
タに転送することもできる。コンピュータで実行する際
には、コンピュータ内のハードディスク装置等にプログ
ラムを格納しておき、メインメモリにロードして実行す
る。
【０３０１】
【発明の効果】以上説明したように、第１の発明では、
メタキャッシュ内のメタデータとともにメタデータがど
のメタボリュームから取り出されたのかを示すメタデー
タ管理情報をログとして採取するようにしたため、保持
されたログがどのメタボリュームのメタデータに関する
ログであるのかを管理することができる。その結果、複
数のログボリュームにメタデータが格納されていても、
ファイルシステムの不整合を修正することが可能とな
る。
【０３０２】また、第２の発明では、ログデータの有効
範囲を管理するようにしたため、ファイルシステムを復
元する際には、ログボリューム１２内の有効なログのみ
を用いて効率よく復元処理を行うことが可能となる。
【０３０３】また、第３の発明では、ログデータに対し
て付与するシーケンス番号の最大値を、システムの使用
可能年数以上使い続けることができる値としたことで、
常に昇順の採番が可能となり、ログボリュームのゼロク
リアに伴う処理の遅延を避けることができる。
【０３０４】また、第４の発明では、メタデータが複数
回更新される場合には、最終形態のみをログとして採取
するようにしたため、ログデータが短縮されるととも
に、ログデータの短縮に伴いファイルシステム復元時間
の短縮が図れる。
【０３０５】また、第５の発明では、割り当て管理情報
の一部の複製を獲得操作用管理情報とし、メタデータの
獲得時には獲得操作用管理情報内から取得すべきメタデ
ータを特定するが、解放時には獲得操作用管理情報の情
報を更新しないようにしたため、メタデータの解放直後
に別のトランザクションにより獲得されることがなくな
る。その結果、システムダウン時に中途までしか終了し
ていなかった解放トランザクションが解放したはずであ
る領域は、解放される直前の状態のまま保全されること
が保証される。
【０３０６】また、第６の発明では、獲得、解放操作の
ログとして、その操作対象となった情報のみを記録する
ようにしたため、ログ採取量が少量ですむ。また、第７
の発明では、複数のログバッファを設け、さらにいくつ
か異なるサイズのログバッファを用意し、トランザクシ
ョン毎のログをそのトランザクションに適したサイズの
ログバッファに格納するようにしたため、複数のトラン
ザクションが並列実行される際のトランザクションの独
立性を高めることができ、また、メモリ空間を有効に活
用できる。
【０３０７】また、第８の発明では、１つのトランザク
ションのログがログバッファに収まらない場合に、中間
ログとして完結されたログをログボリュームに書き出す
ようにしたため、部分的であるログを、ファイル復元時
には１つのトランザクションのログと同値に扱うことが
可能となり、ファイルシステムの復元時に望ましい状態
に復元するのが容易となる。
【０３０８】また、第９の発明では、ログ採取に関する
システムの状態よってトランザクションの受け入れを制
限するようにしたため、複数のトランザクションが並列
実行されることによるメモリ枯渇等の障害の発生を防止
することができる。
【図面の簡単な説明】
【図１】第１の発明の原理構成図である。
【図２】第２の発明の原理構成図である。
【図３】第３の発明の原理構成図である。
【図４】第４の発明の原理構成図である。
【図５】第５の発明の原理構成図である。
【図６】第６の発明の原理構成図である。
【図７】第７の発明の原理構成図である。
【図８】第８の発明の原理構成図である。
【図９】第９の発明の原理構成図である。
【図１０】本発明を適用するデータ処理装置のハードウ
ェア構成図である。
【図１１】ファイルシステム上で動作するログ採取機能
の構成図である。
【図１２】メタデータ管理情報を示す図である。
【図１３】ログバッファの形式を示す図である。
【図１４】有効範囲を説明する図である。
【図１５】ログ採取処理のフローチャートである。
【図１６】メタボリュームの割り当て管理状況を示す図
である。
【図１７】ビットマップによるメタデータ獲得処理を示
すフローチャートである。
【図１８】解放処理のフローチャートである。
【図１９】トランザクションの処理の獲得と終了の状況
を示す図である。
【図２０】ログバッファへのログの格納状況を示す図で
ある。
【図２１】ログ採取手順を示すフローチャートである。
【図２２】ファイルシステム復元処理を示すフローチャ
ートである。
【図２３】新規トランザクションの受け入れ許否判定処
理を示すフローチャートである。
【符号の説明】
１ａ〜１ｃ メタボリューム ２ ログボリューム ３ メタキャッシュ ４ メタデータ読み込み手段 ５ メタデータ管理情報 ６ トランザクション ７ ログ採取手段 ８ ログバッファ ９ ログ書き込み手段
【手続補正書】
【提出日】平成１２年２月２２日（２０００．２．２
２）
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正内容】
【書類名】 明細書
【発明の名称】 データ処理装置及び記録媒体
【特許請求の範囲】
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】本発明はファイルシステムの
修正機能を有するデータ処理装置及び記録媒体に関し、
特にログを用いてファイルシステムの不整合の修正を行
うデータ処理装置及び記録媒体に関する。
【０００２】
【従来の技術】コンピュータシステムを運用している
と、何らかの理由によりシステムがダウンする場合があ
る。突然のシステムダウンが発生すると、ファイルシス
テムの不整合が生じる。そこで、システムダウン後のブ
ート時には、従来であればファイルシステム全体を走査
し、その矛盾点の検出を行う。矛盾点が発見されたら、
場合に応じた変更をファイルシステムに加えることによ
って、ファイルシステムの整合性を回復していた。とこ
ろが、ファイルシステム全体を走査するには多くの時間
が必要であり、結果としてシステムダウン後の復旧の遅
れを招いていた。
【０００３】そこで近代のＵＮＩＸオペレーティングシ
ステム（ＯＳ）のような多くのコンピュータＯＳのファ
イルシステムでは、ファイルシステムオペレーションに
おいてファイルシステムに保存されているデータが更新
される度に、その更新情報をログ（ジャーナル）として
採取している。ファイルシステムオペレーション時に更
新情報のログ採取を行っておくことにより、システムダ
ウン後のブート時のファイルシステム整合性チェックの
フェーズでは、残されたログを順次走査し、対応する領
域へアップデートすることによって、ファイルシステム
の整合性が保証される。その結果、システムのダウン時
間が短縮される。
【０００４】
【発明が解決しようとする課題】しかし、ログ機構を導
入することにより、次に挙げる問題が生じていた。 （１）第１の問題点 ファイルを管理するメタデータ（二次記憶装置に格納さ
れたファイルを管理するためのデータ）は、ファイルシ
ステムオペレーション時に二次記憶装置からメモリへ読
み込まれ、メモリ内において操作される。その後、所定
のタイミングで二次記憶装置へとその更新内容が反映さ
れる。ログ機構の導入時には、その二次記憶装置への反
映前に更新内容をログ専用の二次記憶装置へと記録する
必要がある。
【０００５】しかし、大規模ファイルシステムに対応す
るために、複数の二次記憶装置がメタデータに割り当て
られ、異なる二次記憶装置に割り当てられたメタデータ
を１つのファイルシステムオペレーションが操作する場
合がある。このファイルシステムオペレーションのログ
を採取する際に、メモリ内のメタデータだけをログとし
て記録していたのでは、残されたログからメタデータ毎
に異なる二次記憶装置を検索するのに時間を消費し、ロ
グ機構導入による最大のメリットである、ファイルシス
テム復元の時間短縮に悪い影響を与える。
【０００６】（２）第２の問題点 同様にファイルシステム復元の時間短縮に悪い影響を与
える要因として、有限なサイズしかないログ専用の二次
記憶装置全体をファイルシステム復元時に探索すること
が考えられる。
【０００７】ログ機構の導入はファイルシステムオペレ
ーションを細分化したトランザクションの完了を常に保
証しつつ動作するため、ログ機構を導入した多くのファ
イルシステムはトランザクションにシーケンス番号を与
え、ファイルシステム復元時にはシーケンス番号をもと
に最古のトランザクションを同定する。そして、最古の
トランザクションからログリプレイと呼ばれるログを用
いたファイルシステム復元操作を開始する。
【０００８】ここで、有限サイズのログ専用の二次記憶
装置内には、ファイルシステムの整合性を復元するため
に欠かせないログが確かに存在する可能性があるが、有
限なサイズを有効利用するためにログ専用の二次記憶装
置は過去のログを上書きしてサイクリックに利用しなけ
ればならない。このような処理を行うには、ある程度以
上古いログが必ず不必要となっていることが前提とな
る。従って、多くのログの内容は既に不必要となってい
る。すなわち、ログ専用の二次記憶装置全体を探索ある
いは反映するのは非効率的である。
【０００９】（３）第３の問題点 最古のトランザクションを特定するためのシーケンス番
号は単調増加であることが要求され、運用途中にオーバ
ーフローによってゼロに戻されてしまうことは許されな
い。これを回避するために、ファイルシステム復元作業
終了時、またはオーバーフロー直前にログ専用の二次記
憶装置全体をゼロクリアし、再度シーケンス番号ゼロか
ら順にトランザクションを処理するのが一般的である。
しかし、ログ専用の二次記憶装置をゼロクリアするため
には多くの時間が必要となる。少なくともシステムの運
用を一時停止する必要があり、サーバ装置などによるサ
ービスの提供を停止せざるを得なくなってしまう。
【００１０】以上の（１）〜（３）の課題はファイルシ
ステム復元時の問題であるが、ログ機構を導入すること
は通常の運用時にも問題を引き起こす可能性を持ってい
る。ログ機構は、メモリ上にログをスプールする手法
や、ログ専用の二次記憶装置として用いられるディスク
の特性を考慮したシーケンシャルアクセスなど、高速化
のための条件は整えられているが、ログの採取の仕方を
熟考しなければ、ログ採取に伴う性能劣化は非常に大き
いものとなりうる。
【００１１】（４）第４の問題点 単一のトランザクション内で、同一データを複数回更新
することは度々あるが、その都度、その同一データに対
するログを採取したのではメモリが不足し、二次記憶装
置へのＩ／Ｏ量が増加する。
【００１２】（５）第５の問題点 ログ機構の導入はトランザクションの順序性を保証し、
終了したトランザクションのログを順に採取することを
要求するために、あるトランザクションが操作したログ
対象データを他のトランザクションが操作することが一
般的に不可能な状況となりうる。ここで、個々のファイ
ルの内容を対象とするトランザクションについては、フ
ァイル単位に排他制御を行うことによって、複数のトラ
ンザクションが並列実行することは比較的容易である。
しかしながら、個々のファイルによらないもの、特に領
域の割り当て情報を操作する場合には、並列実行がきわ
めて難しくなる。
【００１３】領域の獲得・解放処理が並列に動作する場
合を考えると、それぞれが獲得、解放のログを採取す
る。同一の管理情報（ここでは、ビットマップを考え
る）によって管理される領域の獲得・解放処理であった
場合には、同一の管理情報が、解放された状態、獲得さ
れた状態でログに記録されることになる。
【００１４】ファイルシステムの復元処理を行わなけれ
ばならないようなシステムダウンが発生するタイミング
によっては、このように別トランザクションの更新情報
を含むログの採取方式では様々な問題が生じる。
【００１５】Ａというトランザクションが解放処理、Ｂ
というトランザクションが獲得処理を行う場合を考え
る。ここで、トランザクションＡの解放処理はトランザ
クションＢの獲得処理よりも先に行われ、かつ、トラン
ザクションＡはトランザクションＢよりも後に終わる場
合を例に挙げる。
【００１６】このとき、トランザクションＡが解放した
領域をトランザクションＢが獲得してしまう場合が考え
られる。トランザクションＢが先に終了することから、
残されたログには、まず獲得処理が記録され、次に解放
処理が記録される。
【００１７】上記の場合のトランザクションＢのログだ
けが記録されており、それを復元に用いた場合には、本
来行われたはずである解放処理の記録が残されていない
ことから、該当領域が二重に獲得された状態となってし
まう。トランザクションＡのログまで記録されており、
復元に用いられると、トランザクションＢが利用してい
る領域がトランザクションＡの解放処理のログによって
解放されている状態となってしまう。いずれも本来の状
態とは異なっており、避けなければならない。しかしな
がら、これを回避するために並列実行を制限すること
は、マルチタスクを実現したＯＳ上のファイルシステム
の速度性能の低下に与える影響が非常に大きい。
【００１８】（６）第６の問題点 既に述べたようにログ機構の第一の目的としてファイル
システムを復元するために費やす時間の短縮が挙げられ
るが、そのためにトランザクションの独立性を疎かにし
たり、中途半端な状態での整合性回復によりあたかも正
常に動作しているかのように振る舞うファイルシステム
が多く見受けられる。
【００１９】従来のメタデータ管理方式のように、ログ
を記録するためのメモリ空間をファイルシステム全体で
１つのキャッシュメモリを共有していたのではトランザ
クション毎の独立性を保つのが難しく、他のトランザク
ションによる更新情報が１つのトランザクションのログ
として記録されてしまう可能性が高い。特にファイルに
対する排他で制御しきれない割り当て管理情報について
は前述の通りである。
【００２０】（７）第７の問題点 トランザクション毎に必要とするログのサイズが異なる
ことから、複数のログバッファとしてログを記録するた
めのメモリをトランザクション毎に割り当て、管理する
場合に、全てのメモリサイズが同一である必要はない。
例えば、ファイルの参照時刻を更新するだけのトランザ
クションが残すログのサイズは大変小さく、巨大なデー
タ書き込み要求のトランザクションは必然的にそれだけ
大きいログサイズとなる。
【００２１】（８）第８の問題点 トランザクション毎に残すログサイズの違いを考慮し
て、限られたメモリ空間の有効利用を試みても、キャッ
シュメモリサイズは残されるログサイズに比較して、や
はり小さい。
【００２２】（９）第９の問題点 「第８の問題点」の解決策として、１つのトランザクシ
ョンを分割し、中途の状態のログを出力することが考え
られる。しかし、一般にファイルを管理するメタデータ
は、トランザクションが中途の状態ではやはり中途の状
態であり、そのままログに記録したところで、そのログ
を用いて復元されるファイルシステムは中途の状態にし
かなり得ない。これではオペレーションのセマンティク
スを保証した復元とはなり得ない。
【００２３】（１０）第１０の問題点 「第９の問題点」で示した中途の状態でのトランザクシ
ョンの中断はファイルシステムにとって危険な状態とい
える。ログ機構の導入は、採取したログをログボリュー
ムに反映するまでは該当メタデータもキャッシュメモリ
から追い出せないことを意味する。ログがキャッシュメ
モリに入りきらないほど巨大となっているときには、メ
タデータを管理するキャッシュメモリの利用率も高くな
っていることが考えられる。ログを出力するまでメタデ
ータをキャッシュメモリから追い出せないため、このよ
うな状態で多くのトランザクションが並列実行される
と、メモリ枯渇によるハングアップ状態に陥ることも考
えられる。
【００２４】（１１）第１１の問題点 第１０の問題点と同様の資源枯渇はログ記録用の二次記
憶装置についても言える。キャッシュメモリに比較すれ
ば巨大な二次記憶装置についても、メタデータ記録用の
二次記憶装置へのＩ／Ｏを削減するために、多くのログ
を有効なログとして残しておけば、それは利用可能な領
域の減少を引き起こす。その際に多数のトランザクショ
ンの並列実行を許すことはメタデータキャッシュ枯渇、
ログキャッシュ枯渇、ログ記録用二次記憶装置枯渇、な
どを誘発する可能性がある。
【００２５】本発明はこのような点に鑑みてなされたも
のであり、ファイルシステム修復処理の効率化を図った
データ処理装置を提供することを目的とする。
【００２６】
【課題を解決するための手段】本発明では上記課題を解
決するための第１の発明として、ログを用いてファイル
システムの不整合の修正を行うデータ処理装置におい
て、ファイルを管理するメタデータを記憶するための二
次記憶装置である複数のメタボリュームと、メタデータ
の更新結果であるログを記憶するための二次記憶装置で
あるログボリュームと、メタデータを記憶するために主
記憶装置内に設けられたメタキャッシュと、メタデータ
の内容が変更される際に、対象となるメタデータを前記
メタキャッシュへと読み込むメタデータ読み込み手段
と、前記メタキャッシュ内に読み込まれたメタデータの
内容を更新するトランザクションと、前記メタキャッシ
ュに読み込まれたメタデータが格納されていたメタボリ
ュームの識別情報を管理するメタデータ管理手段と、前
記メタキャッシュ内で変更されたメタデータの内容をロ
グとして採取するとともに、採取したメタデータが格納
されていたメタボリュームの識別情報を採取するログ採
取手段と、前記ログ採取手段が採取した情報を保持する
ログバッファと、前記ログバッファが保持する情報を、
適宜前記ログボリュームに格納するログ書き込み手段
と、を有することを特徴とするデータ処理装置が提供さ
れる。
【００２７】このようなデータ処理装置によれば、トラ
ンザクションがメタデータの更新をする際には、まず、
メタデータ読み込み手段によりメタボリューム内の必要
なメタデータがメタキャッシュに読み込まれる。その
際、読み込んだメタデータがどのメタボリュームから読
み込まれたものであるのかが、メタデータ管理手段によ
って管理される。ここで、トランザクションがメタデー
タの内容を更新すると、ログ採取手段によって更新後の
メタデータがログとして採取される。この際、メタデー
タが格納されていたメタボリュームの識別情報をも採取
する。採取した情報は、ログバッファに保持される。そ
して、ログ書き込み手段により、ログバッファ内の情報
がログボリュームに書き込まれる。
【００２８】また、上記課題を解決する第２の発明とし
て、ログを用いてファイルシステムの不整合の修正を行
うデータ処理装置において、ファイルを管理するメタデ
ータを記憶するための二次記憶装置であるメタボリュー
ムと、メタデータの更新結果であるログを記憶するため
の二次記憶装置であるログボリュームと、メタデータを
記憶するために主記憶装置内に設けられたメタキャッシ
ュと、メタデータの内容が変更される際に、対象となる
メタデータを前記メタキャッシュへと読み込むメタデー
タ読み込み手段と、前記メタキャッシュ内に読み込まれ
たメタデータの内容を更新するトランザクションと、前
記メタキャッシュ内で変更されたメタデータの内容をロ
グとして採取するログ採取手段と、前記ログ採取手段が
採取した情報を保持するログバッファと、前記ログボリ
ューム内の領域を定期的に循環するようにして、前記ロ
グバッファが保持する情報を前記ログボリュームに格納
するログ書き込み手段と、前記メタキャッシュ内のメタ
データをメタボリューム内に格納するメタデータ書き込
み手段と、前記メタデータ書き込み手段による書き込み
動作を監視しており、変更内容が前記メタボリュームに
反映されていないメタデータに対応する前記ログボリュ
ーム内のログを、有効なログとして指定する有効範囲監
視手段と、ファイルシステム復元要求を受け取ると、前
記ログボリュームに格納されたログの中で、前記有効範
囲監視手段により有効なログとして指定されているログ
のみを用いて、前記メタボリューム内のメタデータの不
整合を修正するファイルシステム復元手段と、を有する
ことを特徴とするデータ処理装置が提供される。
【００２９】このようなデータ処理装置によれば、トラ
ンザクションがメタデータの更新をする際には、まず、
メタデータ読み込み手段によりメタボリューム内の必要
なメタデータがメタキャッシュに読み込まれる。ここ
で、トランザクションがメタデータの内容を更新する
と、ログ採取手段によって更新後のメタデータがログと
して採取される。採取した情報は、ログバッファに保持
される。そして、ログ書き込み手段により、ログバッフ
ァ内の情報がログボリュームに書き込まれる。その後、
メタデータ書き込み手段により、メタキャッシュ内のメ
タデータがメタボリューム内に格納される。その書き込
み動作は、有効範囲監視手段で監視されており、変更内
容がメタボリュームに反映されていないメタデータに対
応するログボリューム内のログが、有効なログとして指
定される。そして、ファイルシステム復元要求が出され
ると、ファイルシステム復元手段により、ログボリュー
ムに格納されたログの中で、有効範囲監視手段により有
効なログとして指定されているログのみを用いて、メタ
ボリューム内のメタデータの不整合が修正される。
【００３０】また、上記課題を解決する第３の発明とし
て、ログを用いてファイルシステムの不整合の修正を行
うデータ処理装置において、ファイルを管理するメタデ
ータを記憶するための二次記憶装置であるメタボリュー
ムと、メタデータの更新結果であるログを記憶するため
の二次記憶装置であるログボリュームと、メタデータを
記憶するために主記憶装置内に設けられたメタキャッシ
ュと、メタデータの内容が変更される際に、対象となる
メタデータを前記メタキャッシュへと読み込むメタデー
タ読み込み手段と、前記メタキャッシュ内に読み込まれ
たメタデータの内容を更新するトランザクションと、前
記メタキャッシュ内で変更されたメタデータの内容をロ
グとして採取するログ採取手段と、前記ログ採取手段が
採取した情報を保持するログバッファと、前記ログバッ
ファが保持する情報を前記ログボリュームに格納するロ
グ書き込み手段と、前記ログボリュームに格納されたロ
グを用いて前記メタボリューム内のメタデータの不整合
を修正するファイルシステム復元手段と、前記ファイル
システム復元手段が前記メタボリューム内のメタデータ
の不整合を修正した時に用いられたログの最後のシーケ
ンス番号を記憶する初期シーケンス番号記憶手段と、
前記ログ書き込み手段がログの書き込みを行う際に、シ
ーケンス番号を昇順で採番し、採番したシーケンス番号
を書き込むべきログに付与しており、前記ファイルシス
テム復元手段が前記メタボリューム内のメタデータの不
整合を修正した直後には、前記初期シーケンス番号記憶
手段に格納されたシーケンス番号を基準として採番する
シーケンス番号採番手段と、を有することを特徴とする
データ処理装置が提供される。
【００３１】このようなデータ処理装置によれば、トラ
ンザクションがメタデータの更新をする際には、まず、
メタデータ読み込み手段によりメタボリューム内の必要
なメタデータがメタキャッシュに読み込まれる。ここ
で、トランザクションがメタデータの内容を更新する
と、ログ採取手段によって更新後のメタデータがログと
して採取される。採取した情報は、ログバッファに保持
される。そして、ログ書き込み手段により、ログバッフ
ァ内の情報がログボリュームに書き込まれる。その際、
シーケンス番号採番手段により、シーケンス番号が昇順
で採番され、書き込むべきログに付与される。ファイル
システムに不整合が発生すると、ファイルシステム復元
手段により、ログボリュームに残されたログを用いてメ
タデータの不整合が修正される。このとき、修正に用い
られた最後のログのシーケンス番号が初期シーケンス番
号記憶手段に記憶される。その後、ログ書き込み手段に
よりログバッファ内の情報がログボリュームに書き込ま
れると、シーケンス番号採番手段により、初期シーケン
ス番号記憶手段に格納されたシーケンス番号を基準とし
てシーケンス番号が採番され、書き込むべきログに付与
される。
【００３２】また、上記課題を解決する第４の発明とし
て、ログを用いてファイルシステムの不整合の修正を行
うデータ処理装置において、ファイルを管理するメタデ
ータを記憶するための二次記憶装置であるメタボリュー
ムと、メタデータを記憶するために主記憶装置内に設け
られたメタキャッシュと、メタデータの内容が変更され
る際に、対象となるメタデータを前記メタキャッシュへ
と読み込むメタデータ読み込み手段と、前記メタキャッ
シュ内に読み込まれたメタデータの内容を更新するトラ
ンザクションと、前記トランザクションの種別を判断
し、メタデータの更新を複数回行う可能性のあるトラン
ザクションの場合には、前記メタキャッシュ内で変更さ
れたメタデータの最終形態のみをログとして採取するロ
グ採取手段と、を有することを特徴とするデータ処理装
置が提供される。
【００３３】このようなデータ処理装置によれば、トラ
ンザクションがメタデータの更新をする際には、まず、
メタデータ読み込み手段によりメタボリューム内の必要
なメタデータがメタキャッシュに読み込まれる。ここ
で、トランザクションがメタデータの内容を更新する。
すると、ログ採取手段により、トランザクションの種別
が判断され、メタデータの更新を複数回行う可能性のあ
るトランザクションの場合には、メタキャッシュ内で変
更されたメタデータの最終形態のみがログとして採取さ
れる。
【００３４】また、上記課題を解決する第５の発明とし
て、ログを用いてファイルシステムの不整合の修正を行
うデータ処理装置において、メタデータに対する割り当
てを管理するための割り当て管理情報を複数の領域に分
割して保持する割り当て管理情報保持手段と、前記割り
当て管理情報保持手段内の割り当て管理情報の一部領域
の複製を生成し、獲得操作用管理情報とするとともに、
前記獲得操作用管理情報内に未獲得のメタデータがなく
なると、割り当て管理情報の別の領域の複製を前記獲得
操作用管理情報とする獲得操作用管理情報生成手段と、
メタデータの獲得及び解放要求を出力するトランザクシ
ョンと、前記トランザクションによりメタデータの獲得
要求が出された場合には、前記獲得操作用管理情報の中
の未獲得のメタデータを獲得し、獲得したメタデータを
獲得済みとするように前記獲得操作用管理情報と前記割
り当て管理情報との内容を変更するメタデータ獲得手段
と、前記トランザクションによりメタデータの解放要求
が出された場合には、指定されたメタデータが未獲得の
状態となるように、前記割り当て管理情報の内容を変更
するメタデータ解放手段と、を有することを特徴とする
データ処理装置が提供される。
【００３５】このようなデータ処理装置によれば、獲得
操作用管理情報生成手段により、割り当て管理情報の一
部領域の複製が生成され、獲得操作用管理情報とされ
る。トランザクションにより獲得要求があると、メタデ
ータ獲得手段により、獲得操作用管理情報内の未獲得の
メタデータが獲得される。すると、獲得操作用管理情報
と割り当て管理情報との内容が更新される。また、トラ
ンザクションよりメタデータの解放要求があると、メタ
データ解放手段により該当するメタデータの解放処理が
行われる。この際、割り当て管理情報の内容のみが更新
される。ここで、獲得操作用管理情報内に未獲得のメタ
データがなくなると、割り当て管理情報内の別の領域の
複製が獲得操作用管理情報とされる。
【００３６】また、上記課題を解決する第６の発明とし
て、ログを用いてファイルシステムの不整合の修正を行
うデータ処理装置において、メタデータに対する割り当
てを管理するための割り当て管理情報を保持する割り当
て管理情報保持手段と、メタデータの獲得及び解放要求
を出力するトランザクションと、前記トランザクション
によりメタデータの獲得要求が出された場合には、前記
割り当て管理情報保持手段の中の未獲得のメタデータを
獲得し、獲得したメタデータを獲得済みとするように前
記割り当て管理情報の内容を変更するメタデータ獲得手
段と、前記トランザクションによりメタデータの解放要
求が出された場合には、指定されたメタデータ未獲得の
状態となるように、前記割り当て管理情報の内容を変更
するメタデータ解放手段と、前記割り当て管理情報内の
前記メタデータ獲得手段及び前記メタデータ解放手段に
よって変更された部分の情報をログとして採取するログ
採取手段と、を有することを特徴とするデータ処理装置
が提供される。
【００３７】このようなデータ処理装置によれば、トラ
ンザクションからメタデータの獲得要求が出されると、
メタデータ獲得手段によって未獲得のメタデータの１つ
が割り当て管理情報内から獲得され、そのメタデータが
獲得済みの状態とされる。また、トランザクションから
メタデータの解放要求が出されると、メタデータ解放手
段によって該当するメタデータが未獲得の状態に変更さ
れる。そして、ログ採取手段により、割り当て管理情報
内のメタデータ獲得手段及びメタデータ解放手段によっ
て変更された部分の情報がログとして採取される。
【００３８】また、上記課題を解決する第７の発明とし
て、ログを用いてファイルシステムの不整合の修正を行
うデータ処理装置において、ファイルを管理するメタデ
ータを記憶するための二次記憶装置であるメタボリュー
ムと、メタデータを記憶するために主記憶装置内に設け
られたメタキャッシュと、メタデータの内容が変更され
る際に、対象となるメタデータを前記メタキャッシュへ
と読み込むメタデータ読み込み手段と、前記メタキャッ
シュ内に読み込まれたメタデータの内容を更新する複数
のトランザクションと、 ログをトランザクション毎に
保持する、サイズの異なる複数のログバッファと、前記
メタキャッシュ内で変更されたメタデータの内容をログ
として採取し、前記トランザクション毎に分けて前記ロ
グバッファに格納するログ採取手段と、を有することを
特徴とするデータ処理装置が提供される。
【００３９】このようなデータ処理装置によれば、トラ
ンザクションがメタデータの更新をする際には、まず、
メタデータ読み込み手段によりメタボリューム内の必要
なメタデータがメタキャッシュに読み込まれる。ここ
で、トランザクションがメタデータの内容を更新する。
すると、ログ採取手段により、メタキャッシュ内で変更
されたメタデータがログとして採取され、トランザクシ
ョン毎のログバッファに保持される。
【００４０】また、上記課題を解決する第８の発明とし
て、ログを用いてファイルシステムの不整合の修正を行
うデータ処理装置において、ファイルを管理するメタデ
ータを記憶するための二次記憶装置であるメタボリュー
ムと、メタデータの更新結果であるログを記憶するため
の二次記憶装置であるログボリュームと、メタデータを
記憶するために主記憶装置内に設けられたメタキャッシ
ュと、メタデータの内容が変更される際に、対象となる
メタデータを前記メタキャッシュへと読み込むメタデー
タ読み込み手段と、前記メタキャッシュ内に読み込まれ
たメタデータの内容を更新するトランザクションと、ロ
グをトランザクション毎に保持するログバッファと、前
記メタキャッシュ内で変更されたメタデータの内容をロ
グとして採取し、前記ログバッファに格納するログ採取
手段と、前記トランザクションが終了した場合に前記ロ
グバッファの内容を前記ログボリュームに書き込むとと
もに、前記トランザクションによるログが前記ログバッ
ファ内に格納しきれない場合には、前記ログバッファ内
のデータを完結したログに加工し、中間ログとして前記
ログボリューム内に格納するログ書き込み手段と、を有
することを特徴とするデータ処理装置が提供される。
【００４１】このようなデータ処理装置によれば、トラ
ンザクションがメタデータの更新をする際には、まず、
メタデータ読み込み手段によりメタボリューム内の必要
なメタデータがメタキャッシュに読み込まれる。ここ
で、トランザクションがメタデータの内容を更新する
と、ログ採取手段によって更新後のメタデータがログと
して採取される。採取した情報は、ログバッファに保持
される。そして、ログバッファに格納しきれなくなる
か、トランザクションが終了すると、ログ書き込み手段
により、ログバッファ内の情報がログボリュームに書き
込まれる。ログバッファに格納しきれなくなった場合に
は、ログバッファの内容を完結したログに加工され、中
間ログとしてログボリュームに格納される。
【００４２】また、上記課題を解決する第９の発明とし
て、ログを用いてファイルシステムの不整合の修正を行
うデータ処理装置において、ファイルを管理するメタデ
ータを記憶するための二次記憶装置であるメタボリュー
ムと、メタデータの更新結果であるログを記憶するため
の二次記憶装置であるログボリュームと、メタデータを
記憶するために主記憶装置内に設けられたメタキャッシ
ュと、メタデータの内容が変更される際に、対象となる
メタデータを前記メタキャッシュへと読み込むメタデー
タ読み込み手段と、前記メタキャッシュ内に読み込まれ
たメタデータの内容を更新する、複数同時実行可能なト
ランザクションと、前記トランザクションからの開始要
求を受け付けると、ログ採取に関するシステムの動作状
況を判断し、前記トランザクションの受け入れ許否を判
断するトランザクション受け入れ判断手段と、前記メタ
キャッシュ内で変更されたメタデータの内容をログとし
て採取するログ採取手段と、前記ログ採取手段が採取し
た情報を保持するログバッファと、前記ログバッファが
保持する情報を、適宜前記ログボリュームに格納するロ
グ書き込み手段と、を有することを特徴とするデータ処
理装置が提供される。
【００４３】このようなデータ処理装置によれば、トラ
ンザクションから開始要求が出されると、トランザクシ
ョン受け入れ制限手段が受け入れの許否を判断する。そ
の後、メタデータ書き込み手段によるメタデータの書き
込みが進み、有効なログの割合が減少したら、その時点
でトランザクションの開始要求を許可する。
【００４４】
【発明の実施の形態】以下、本発明の実施の形態を図面
を参照して説明する。図１は、第１の発明の原理構成図
である。この第１の発明は、複数の二次記憶装置がメタ
データに割り当てられている場合におけるファイルシス
テム不整合修復時間の短縮を図るものである。
【００４５】このデータ処理装置には、二次記憶装置と
してメタボリューム１ａ，１ｂ，１ｃとログボリューム
２とが設けられている。各メタボリューム１ａ，１ｂ，
１ｃには、ファイルを管理するためのメタデータが記憶
されている。また、ログボリューム２には、メタデータ
の更新結果であるログが記憶されている。また、主記憶
装置内にはメタキャッシュ３が設けられている。メタキ
ャッシュ３は、メタデータを記憶するための主記憶装置
内の記憶領域である。メタデータ読み込み手段４は、メ
タデータの内容が変更される際に、対象となるメタデー
タをメタキャッシュ３へと読み込む。メタデータ管理手
段５は、メタキャッシュ３に読み込まれたメタデータが
格納されていたメタボリューム１ａ，１ｂ，１ｃの識別
情報を管理する。トランザクション６は、メタキャッシ
ュ３内に読み込まれたメタデータの内容を更新する。ロ
グ採取手段７は、メタキャッシュ３内で変更されたメタ
データの内容をログとして採取するとともに、採取した
メタデータが格納されていたメタボリューム１ａ，１
ｂ，１ｃの識別情報を採取する。ログバッファ８は、ロ
グ採取手段７が採取した情報を保持する。ログ書き込み
手段９は、ログバッファ８が保持する情報を、適宜ログ
ボリューム２に格納する。
【００４６】このようなデータ処理装置によれば、トラ
ンザクション６がメタデータの更新をする際には、ま
ず、メタデータ読み込み手段４によりメタボリューム１
ａ〜１ｃ内の必要なメタデータがメタキャッシュ３に読
み込まれる。その際、読み込んだメタデータがどのメタ
ボリュームから読み込まれたものであるのかが、メタデ
ータ管理手段５によって管理される。ここで、トランザ
クション６がメタデータの内容を更新すると、ログ採取
手段７によって更新後のメタデータがログとして採取さ
れる。この際、メタデータが格納されていたメタボリュ
ーム１ａ〜１ｃの識別情報をも採取する。採取した情報
は、ログバッファ８に保持される。そして、ログ書き込
み手段９により、ログバッファ８内の情報がログボリュ
ーム２に書き込まれる。
【００４７】これにより、ログボリューム２に保持され
たログがどのメタボリューム１ａ〜１ｃのメタデータに
関するログであるのかを管理することができる。その結
果、複数のメタボリューム１ａ〜１ｃにメタデータが格
納されていても、ファイルシステムの不整合を修正する
ことが可能となる。
【００４８】図２は、第２の発明の原理構成図である。
第２の発明は、ログの有効範囲を監視することで、ファ
イルシステム復元時の効率化を図ったものである。第２
の発明は、以下のような要素で構成される。
【００４９】メタボリューム１１は、ファイルを管理す
るメタデータを記憶するための二次記憶装置である。ロ
グボリューム１２は、メタデータの更新結果であるログ
を記憶するための二次記憶装置である。メタキャッシュ
１３は、メタデータを記憶するために主記憶装置内に設
けられた記憶領域である。メタデータ読み込み手段１４
は、メタデータの内容が変更される際に、対象となるメ
タデータをメタキャッシュ１３へと読み込む。トランザ
クション１５は、メタキャッシュ１３内に読み込まれた
メタデータの内容を更新する。ログ採取手段１６は、メ
タキャッシュ１３内で変更されたメタデータの内容をロ
グとして採取するとともに、採取したメタデータが格納
されていたメタボリュームの識別情報を採取する。ログ
バッファ１７は、ログ採取手段１６が採取した情報を保
持する。ログ書き込み手段１８は、ログボリューム１２
内の領域を定期的に循環するようにして、ログバッファ
１７が保持する情報をログボリューム１２に格納する。
メタデータ書き込み手段１９は、メタキャッシュ１３内
のメタデータをメタボリューム１１内に格納する。有効
範囲監視手段２０は、メタデータ書き込み手段１９によ
る書き込み動作を監視しており、変更内容がメタボリュ
ーム１１に反映されていないメタデータに対応するログ
ボリューム１２内のログを、有効なログとして指定す
る。ファイルシステム復元手段２１は、ファイルシステ
ム復元要求を受け取ると、ログボリューム１２に格納さ
れたログの中で、有効範囲監視手段２０により有効なロ
グとして指定されているログのみを用いて、メタボリュ
ーム１１内のメタデータの不整合を修正する。なお、有
効範囲監視手段２０による有効なログの指定方法として
は、例えば、有効範囲を示す情報を不揮発性の記録媒体
（ログボリューム１２等）に記録することができる。こ
の場合、ファイルシステム復元手段２１は、有効範囲が
記録された不揮発性の記録媒体内の情報を読みとること
で、有効なログと指定されているログを認識できる。
【００５０】このようなデータ処理装置によれば、トラ
ンザクション１５がメタデータの更新をする際には、ま
ず、メタデータ読み込み手段１４によりメタボリューム
１１内の必要なメタデータがメタキャッシュ１３に読み
込まれる。ここで、トランザクション１５がメタデータ
の内容を更新すると、ログ採取手段１６によって更新後
のメタデータがログとして採取される。採取した情報
は、ログバッファ１７に保持される。そして、ログ書き
込み手段１８により、ログバッファ１７内の情報がログ
ボリューム１２に書き込まれる。その後、メタデータ書
き込み手段１９により、メタキャッシュ１３内のメタデ
ータがメタボリューム１１内に格納される。その書き込
み動作は、有効範囲監視手段２０で監視されており、変
更内容がメタボリューム１１に反映されていないメタデ
ータに対応するログボリューム１２内のログが、有効な
ログとして指定される。そして、ファイルシステム復元
要求が出されると、ファイルシステム復元手段２１によ
り、ログボリューム１２に格納されたログの中で、有効
範囲監視手段２０により有効なログとして指定されてい
るログを用いて、メタボリューム１１内のメタデータの
不整合が修正される。
【００５１】これにより、ファイルシステムを復元する
際には、ログボリューム１２内の有効なログのみを用い
て効率よく復元処理を行うことが可能となる。図３は、
第３の発明の原理構成図である。第３の発明は、ログに
付加するシーケンス番号のデータサイズを十分大きなも
のとし、シーケンス番号を常に昇順で使い続けることが
できる（ゼロクリアが不要となる）ようにしたものであ
る。第３の実施の形態は、以下のような要素で構成され
る。
【００５２】メタボリューム３１は、ファイルを管理す
るメタデータを記憶するための二次記憶装置である。ロ
グボリューム３２は、メタデータの更新結果であるログ
を記憶するための二次記憶装置である。メタキャッシュ
３３は、メタデータを記憶するために主記憶装置内に設
けられた記憶領域である。メタデータ読み込み手段３４
は、メタデータの内容が変更される際に、対象となるメ
タデータをメタキャッシュ３３へと読み込む。トランザ
クション３５は、メタキャッシュ３３内に読み込まれた
メタデータの内容を更新する。ログ採取手段３６は、メ
タキャッシュ３３内で変更されたメタデータの内容をロ
グとして採取する。ログバッファ３７は、ログ採取手段
３６が採取した情報を保持する。ログ書き込み手段３８
は、ログバッファが保持する情報を前記ログボリューム
に格納する。ファイルシステム復元手段３９は、ログボ
リューム３２に格納されたログを用いてメタボリューム
３１内のメタデータの不整合を修正する。初期シーケン
ス番号記憶手段３０ａは、ファイルシステム復元手段３
９がメタボリューム３１内のメタデータの不整合を修正
した時に用いられたログの最後のシーケンス番号を記憶
する。シーケンス番号採番手段３０ｂは、ログ書き込み
手段３８がログの書き込みを行う際に、シーケンス番号
を昇順で採番し、採番したシーケンス番号を書き込むべ
きログに付与しており、ファイルシステム復元手段３９
がメタボリューム３１内のメタデータの不整合を修正し
た直後には、初期シーケンス番号記憶手段３０ａに格納
されたシーケンス番号を基準として採番する。
【００５３】このようなデータ処理装置によれば、トラ
ンザクション３５がメタデータの更新をする際には、ま
ず、メタデータ読み込み手段３４によりメタボリューム
３１内の必要なメタデータがメタキャッシュ３３に読み
込まれる。ここで、トランザクション３５がメタデータ
の内容を更新すると、ログ採取手段３６によって更新後
のメタデータがログとして採取される。採取した情報
は、ログバッファ３７に保持される。そして、ログ書き
込み手段３８により、ログバッファ３７内の情報がログ
ボリューム３２に書き込まれる。その際、シーケンス番
号採番手段３０ｂによりシーケンス番号が昇順で採番さ
れ、書き込むべきログに付与される。また、ファイルシ
ステム復元手段３９により、ログボリューム３２に格納
されたログを用いてメタボリューム３１内のメタデータ
の不整合が修正されると、修正した時に用いられたログ
の最後のシーケンス番号が初期シーケンス番号記憶手段
３０ａに記憶される。その後、ログ書き込み手段３８に
より、ログバッファ３７内の情報がログボリューム３２
に書き込まれると、シーケンス番号採番手段３０ｂによ
り、初期シーケンス番号記憶手段３０ａに記憶されたシ
ーケンス番号を基準としてシーケンス番号が昇順で採番
され、書き込むべきログに付与される。
【００５４】これにより、既にファイルシステムの復元
に用いたログと、ファイルシステム復元後に介したトラ
ンザクションのログとのシーケンス番号が重ならないこ
とを保証することができる。その結果、システムが使用
可能な期間中にログボリュームをゼロクリアする必要が
なくなり、ゼロクリアに伴う処理の遅延を避けることが
できる。
【００５５】図４は、第４の発明の原理構成図である。
第４の発明は、同じメタデータに対して複数回更新処理
が行われる場合に、最終形態のメタデータのみをログと
して採取するものである。第４の発明は、以下のような
要素で構成される。
【００５６】メタボリューム４１は、ファイルを管理す
るメタデータを記憶するための二次記憶装置である。メ
タキャッシュ４２は、メタデータを記憶するために主記
憶装置内に設けられた記憶領域である。メタデータ読み
込み手段４３は、メタデータの内容が変更される際に、
対象となるメタデータをメタキャッシュ４２へと読み込
む。トランザクション４４は、メタキャッシュ４２内に
読み込まれたメタデータの内容を更新する。ログ採取手
段４５は、トランザクション４４の種別を判断し、メタ
データの更新を複数回行う可能性のあるトランザクショ
ンの場合には、メタキャッシュ４２内で変更されたメタ
データの最終形態のみをログとして採取する。ログバッ
ファ４６は、ログ採取手段４５が採取した情報を保持す
る。
【００５７】このようなデータ処理装置によれば、トラ
ンザクション４４がメタデータの更新をする際には、ま
ず、メタデータ読み込み手段４３によりメタボリューム
４１内の必要なメタデータがメタキャッシュ４２に読み
込まれる。ここで、トランザクション４４がメタデータ
の内容を更新する。すると、ログ採取手段４５により、
トランザクション４４の種別が判断され、メタデータの
更新を複数回行う可能性のあるメタデータ属性を予測す
る。予測されたメタデータ属性において、同一メタデー
タが何度も更新される可能性がある場合には、その属性
のメタデータがメタキャッシュ４２内で変更された時点
ではログ採取を行わず、トランザクション４４が終了し
た時点で、最終形態のメタデータをログとして採取す
る。採取した情報は、ログバッファ４６に保持される。
【００５８】これにより、複数回更新されたメタデータ
のログを更新処理の度に採取することがなくなり、メモ
リの効率化を図ることができるともに、ログを書き出す
ときのＩ／Ｏの量も減らすことができる。
【００５９】図５は、第５の発明の原理構成図である。
第５の発明は、メタデータ割り当て管理情報の一部の複
製を生成し、複製として生成した情報内からのみメタデ
ータの獲得を可能とし、解放する際には、割り当て管理
情報においてのみ解放された旨の情報の更新を行うこと
で、解放直後に別のトランザクションに獲得されるのを
防止したものである。第５の発明は、以下のような要素
で構成される。
【００６０】割り当て管理情報保持手段５１は、メタデ
ータに対する割り当てを管理するための割り当て管理情
報５１ａを複数の領域に分割して保持する。獲得操作用
管理情報生成手段５２は、割り当て管理情報保持手段５
１内の割り当て管理情報の一部領域の複製を生成し、獲
得操作用管理情報５１ｂとする。また、獲得操作用管理
情報５１ｂ内に未獲得のメタデータがなくなると、割り
当て管理情報の別の領域の複製を獲得操作用管理情報５
１ｂとする。トランザクション５３は、メタデータの獲
得及び解放要求を出力する。メタデータ獲得手段５４
は、トランザクション５３によりメタデータの獲得要求
が出された場合には、獲得操作用管理情報５１ｂの中の
未獲得のメタデータを獲得し、獲得したメタデータを獲
得済みとするように獲得操作用管理情報５１ｂと割り当
て管理情報５１ａとの内容を変更する。メタデータ解放
手段５５は、トランザクション５３によりメタデータの
解放要求が出された場合には、指定されたメタデータが
未獲得の状態となるように、割り当て管理情報の内容を
変更する。
【００６１】このようなデータ処理装置によれば、獲得
操作用管理情報生成手段５２により、割り当て管理情報
５１ａの一部領域の複製が生成され、獲得操作用管理情
報５１ｂとされる。トランザクション５３により獲得要
求があると、メタデータ獲得手段５４により、獲得操作
用管理情報５１ｂ内の未獲得のメタデータが獲得され
る。すると、獲得操作用管理情報５１ｂと割り当て管理
情報５１ａとの内容が更新される。また、トランザクシ
ョン５３よりメタデータの解放要求があると、メタデー
タ解放手段５５により該当するメタデータの解放処理が
行われる。この際、割り当て管理情報５１ａの内容のみ
が更新される。ここで、獲得操作用管理情報５１ｂ内に
未獲得のメタデータがなくなると、割り当て管理情報５
１ａ内の別の領域の複製が獲得操作用管理情報５１ｂと
される。
【００６２】これにより、解放された旨の情報が獲得操
作用管理情報５１ｂに反映されないため、解放直後のメ
タデータが他のトランザクションに獲得されることがな
くなる。その結果、解放処理を行ったトランザクション
の終了前にシステムがダウンしても、少なくとも解放前
の状態のまま保全されることが保証される。
【００６３】図６は、第６の発明の原理構成図である。
第６の発明は、トランザクション単位に、獲得や解放に
関する情報をログとして記録することで、必要なメモリ
容量の削減を図るとともに、平行動作するトランザクシ
ョンのログに起因して割り当て管理情報に不正な状態が
発生することを防ぐものである。第６の発明は、以下の
ような要素で構成される。
【００６４】割り当て管理情報保持手段６１は、メタデ
ータに対する割り当てを管理するための割り当て管理情
報を保持する。トランザクション６２は、メタデータの
獲得及び解放要求を出力する。メタデータ獲得手段６３
は、トランザクション６２によりメタデータの獲得要求
が出された場合には、獲得操作用管理情報の中の未獲得
のメタデータを獲得し、獲得したメタデータを獲得済み
とするように割り当て管理情報６１ａの内容を変更す
る。メタデータ解放手段６４は、トランザクション６２
によりメタデータの解放要求が出された場合には、指定
されたメタデータ未獲得の状態となるように、割り当て
管理情報６１ａの内容を変更する。ログ採取手段６５
は、割り当て管理情報内のメタデータ獲得手段６３及び
メタデータ解放手段６４によって変更された部分の情報
をログとして採取する。ログバッファ６６は、ログ採取
手段６５が採取したログを保持する。
【００６５】このようなデータ処理装置によれば、トラ
ンザクション６２からメタデータの獲得要求が出される
と、メタデータ獲得手段６３によって未獲得のメタデー
タの１つが割り当て管理情報６１ａ内から獲得され、そ
のメタデータが獲得済みの状態とされる。また、トラン
ザクション６２からメタデータの解放要求が出される
と、メタデータ解放手段６４によって該当するメタデー
タが未獲得の状態に変更される。そして、ログ採取手段
６５により、割り当て管理情報６１ａ内のメタデータ獲
得手段６３及びメタデータ解放手段６４によって変更さ
れた部分の情報がログとして採取され、ログバッファ６
６に保持される。
【００６６】このように、獲得、解放のログを採取する
際に、トランザクションが獲得や解放を行ったという情
報のみをログとして格納することで、メモリ等の領域を
効率よく利用することができるとともに、他トランザク
ションによる獲得や解放処理の情報がログに含まれない
ことによって、割り当て管理情報が不正な状態となるこ
とを防ぐことができる。
【００６７】図７は、第７の発明の原理構成図である。
第７の発明は、ログバッファを複数設けることにより、
トランザクションの独立性をいっそう高めたものであ
る。第７の発明の構成要素は以下の通りである。
【００６８】メタボリューム７１は、ファイルを管理す
るメタデータを記憶するための二次記憶装置である。メ
タキャッシュ７２は、メタデータを記憶するために主記
憶装置内に設けられた記憶領域である。メタデータ読み
込み手段７３は、メタデータの内容が変更される際に、
対象となるメタデータをメタキャッシュ７２へと読み込
む。複数のトランザクション７４ａ〜７４ｃは、メタキ
ャッシュ７２内に読み込まれたメタデータの内容を更新
する。複数のログバッファ７５ａ〜７５ｅは、ログをト
ランザクション毎に保持する。各ログバッファ７５ａ〜
７５ｅのサイズは一定ではなく、大きなサイズや小さな
サイズが存在する。ログ採取手段７６は、メタキャッシ
ュ７２内で変更されたメタデータの内容をログとして採
取し、前記トランザクション毎に分けて適したサイズの
ログバッファ７５ａ〜７５ｅに格納する。例えば、最初
にログを格納する場合には、トランザクションの内容に
よって予想される処理に適した大きさのログバッファに
格納し、格納対象となるログバッファの記憶容量が不足
してきたら、より大きな記憶容量のログバッファへログ
を移し替え、以後、より大きな記憶容量のログバッファ
をログの格納対象とする。
【００６９】このようなデータ処理装置によれば、トラ
ンザクション７４ａ〜７４ｃがメタデータの更新をする
際には、まず、メタデータ読み込み手段７３によりメタ
ボリューム７１内の必要なメタデータがメタキャッシュ
７２に読み込まれる。ここで、トランザクション７４ａ
〜７４ｃがメタデータの内容を更新する。すると、ログ
採取手段７６により、メタキャッシュ７２内で変更され
たメタデータがログとして採取され、適したサイズのロ
グバッファ７５ａ〜７５ｅに保持される。
【００７０】このように、複数のログバッファに分け、
トランザクション毎に１つのログバッファを使用するよ
うにしたことで、トランザクションの独立性を保つこと
ができる。しかも、複数のサイズのログバッファを用意
し、トランザクション毎に適したサイズのログバッファ
を使用することにより、メモリを効率的に利用できる。
【００７１】図８は、第８の発明の原理構成図である。
第８の発明は、あるトランザクションのログがログバッ
ファに入りきらない場合に、中間ログとしてログバッフ
ァの内容を書き出すものである。第８の発明の構成は以
下の通りである。
【００７２】メタボリューム８１は、ファイルを管理す
るメタデータを記憶するための二次記憶装置である。ロ
グボリューム８２は、メタデータの更新結果であるログ
を記憶するための二次記憶装置である。メタキャッシュ
８３は、メタデータを記憶するために主記憶装置内に設
けられた記憶領域である。メタデータ読み込み手段８４
は、メタデータの内容が変更される際に、対象となるメ
タデータをメタキャッシュ８３へと読み込む。トランザ
クション８５は、メタキャッシュ８３内に読み込まれた
メタデータの内容を更新する。ログバッファ８６は、ロ
グをトランザクション毎に保持する。ログ採取手段８７
は、メタキャッシュ８３内で変更されたメタデータの内
容をログとして採取し、ログバッファ８６に格納する。
ログ書き込み手段８８は、トランザクション８５が終了
した場合にログバッファ８６の内容をログボリューム８
２に書き込むとともに、トランザクション８５によるロ
グがログバッファ８６内に格納しきれない場合には、ロ
グバッファ８６内のデータを完結したログに加工し、中
間ログとしてログボリューム８２内に格納する。なお、
中間ログを生成する際には、中間ログに対してトランザ
クションを実行するのに必要とされたパラメタに関する
情報を付加する。ファイルシステム復元手段８９は、フ
ァイルシステム復元要求を受け取ると、ログボリューム
８２に格納されたログを用いて、メタボリューム８１内
のメタデータの不整合を修正する。このとき、中間ログ
を発見すると、中間ログに含まれたパラメタを用いてト
ランザクションを再実行させる。
【００７３】このようなデータ処理装置によれば、トラ
ンザクション８５がメタデータの更新をする際には、ま
ず、メタデータ読み込み手段８４によりメタボリューム
８１内の必要なメタデータがメタキャッシュ８３に読み
込まれる。ここで、トランザクション８５がメタデータ
の内容を更新すると、ログ採取手段８７によって更新後
のメタデータがログとして採取される。採取した情報
は、ログバッファ８６に保持される。そして、ログバッ
ファ８６に格納しきれなくなるか、トランザクション８
５が終了すると、ログ書き込み手段８８により、ログバ
ッファ８６内の情報がログボリューム８２に書き込まれ
る。ログバッファ８６に格納しきれなくなった場合に
は、ログバッファ８６の内容を完結したログに加工し、
中間ログとしてログボリューム８２に格納する。そし
て、ファイルシステム復元要求が出されると、ファイル
システム復元手段８９により、ログボリューム８２に格
納されたログを用いて、メタボリューム８１内のメタデ
ータの不整合が修正されるとともに、中間ログまで採取
した段階で停止しているトランザクションが再実行され
る。
【００７４】これにより、メタデータの更新を大量に行
うトランザクションの実行中にシステムがダウンした場
合には、途中の状態まで戻すことができるとともに、ト
ランザクションが再実行されることで、トランザクショ
ンの実行後の状態へ遷移させることができる。
【００７５】図９は、第９の発明の原理構成図である。
トランザクションの受け入れを一定の条件によって制限
することで、メモリ枯渇等を防止するものである。第９
の発明の構成は以下の通りである。
【００７６】メタボリューム９１は、ファイルを管理す
るメタデータを記憶するための二次記憶装置である。ロ
グボリューム９２は、メタデータの更新結果であるログ
を記憶するための二次記憶装置である。メタキャッシュ
９４は、メタデータを記憶するために主記憶装置内に設
けられた記憶領域である。メタデータ読み込み手段９３
は、メタデータの内容が変更される際に、対象となるメ
タデータをメタキャッシュ９４へと読み込む。互いの同
時実行可能な複数のトランザクション９０ｂ〜９０ｄ
は、メタキャッシュ９４内に読み込まれたメタデータの
内容を更新する。トランザクション受け入れ制限手段９
０ａは、トランザクション９０ｂ〜９０ｄからの開始要
求を受け付けると、ログ採取に関するシステムの動作状
況に基づいて、トランザクション９０ｂ〜９０ｄの受け
入れ許否を判断する。受け入れ判断基準としては、例え
ばログボリューム内の有効なログが占める割合を用い
る。すなわち、有効範囲監視手段９９によって有効なロ
グとされたログがログボリューム中に占める割合が一定
値以上である間は、トランザクション９０ｂ〜９０ｄの
受け入れを拒絶する。
【００７７】ログ採取手段９６は、メタキャッシュ９４
内で変更されたメタデータの内容をログとして採取す
る。ログバッファ９５は、ログ採取手段９６が採取した
情報を保持する。ログ書き込み手段９７は、ログバッフ
ァ９５が保持する情報を、適宜ログボリューム９２に格
納する。メタデータ書き込み手段９８は、メタキャッシ
ュ９４内のメタデータをメタボリューム９１内に格納す
る。有効範囲監視手段９９は、メタデータ書き込み手段
９８による書き込み動作を監視しており、変更内容が前
記メタボリュームに反映されていないメタデータに対応
するログボリューム９２内のログを、有効なログとして
指定する。
【００７８】このようなデータ処理装置によれば、トラ
ンザクション９０ｂ〜９０ｄから開始要求が出される
と、トランザクション受け入れ制限手段９０ａが受け入
れの許否を判断する。例えば、有効範囲監視手段９９に
より有効であると指定されたログのログボリューム９２
内に示す割合が一定以上の場合には、それ以上ログが発
生しないように、トランザクションの受け入れを拒絶す
る。その後、メタデータ書き込み手段９８によるメタデ
ータの書き込みが進み、有効なログの割合が減少した
ら、その時点でトランザクションの開始要求を許可す
る。
【００７９】これにより、ログボリュームの空き容量の
減少に伴うハングアップなどの障害の発生を防止するこ
とができる。次に、本発明の実施の形態を具体的に説明
する。
【００８０】図１０は、本発明を適用するデータ処理装
置のハードウェア構成図である。データ処理システム
は、ＣＰＵ(Central Processing Unit)２１１を中心に
構成されている。ＣＰＵ２１１は、バス２１７を介して
他の機器を制御するとともに、様々なデータ処理を行
う。バス２１７には、メモリ２１２、入力機器インタフ
ェース２１３、表示制御回路２１４、ＨＤＤ(Hard Disk
Drive)インタフェース２１５、及びネットワークイン
タフェース２１６が接続されている。
【００８１】メモリ２１２は、ＣＰＵ２１１が実行すべ
きプログラムや、プログラムの実行に必要な各種データ
を一時的に保持する。入力機器インタフェース２１３
は、入力機器としてキーボード２２１とマウス２２２が
接続されており、これらの入力機器からの入力内容をＣ
ＰＵ２１１に伝える。
【００８２】表示制御回路２１４は、表示装置２２３が
接続されており、ＣＰＵ２１１から送られてきた画像デ
ータを表示装置２２３で表示可能な画像情報に変換し、
表示装置２２３の画面に表示させる。
【００８３】ＨＤＤインタフェース２１５は、複数のＨ
ＤＤ２３１〜２３３が接続されており、ＣＰＵ２１１か
ら送られてきたデータをＨＤＤ２３１〜２３３に格納す
るとともに、ＣＰＵ２１１からの要求に応じてＨＤＤ２
３１〜２３３内のデータを読み取り、ＣＰＵ２１１に転
送する。
【００８４】ネットワークインタフェース２１６は、Ｌ
ＡＮ(Local Area Network)に接続されており、ＬＡＮを
介してデータ通信を行う。すなわち、ＣＰＵ２１１から
送られたデータをＬＡＮに接続された他のコンピュータ
に転送するとともに、他のコンピュータからＬＡＮを介
して送られてきたデータをＣＰＵ２１１に転送する。
【００８５】ＨＤＤ２３１〜２３３には、各種ファイル
や、そのファイルを管理するためのメタデータ及びログ
が格納されている。このような構成のシステムにおい
て、ＣＰＵ２１１がＨＤＤ２３１〜２３３に格納された
オペレーティングシステム用のプログラムを実行するこ
とにより、本発明のログ採取機能が実現される。
【００８６】図１１は、ファイルシステム上で動作する
ログ採取機能の構成図である。図のように、ファイルを
管理するためのメタボリューム１１１〜１１３も複数設
けられている。メタボリューム１１１〜１１３には、そ
れぞれメタデータが格納されている。メタデータは、フ
ァイルの格納場所等を管理するために必要な情報を有し
ている。
【００８７】ログボリューム１２０は、ログ１２２を格
納するための二次記憶装置である。ログボリューム１２
０には、ログ１２２の他にボリューム管理情報１２１が
格納されている。
【００８８】メタキャッシュ１３０は、メタデータを操
作するためのメモリ上の領域である。メタキャッシュ１
３０内には、操作対象となるメタデータ１３２とそのメ
タデータの割り当て管理情報１３１とが格納される。
【００８９】ログキャッシュ１４０は、複数のログバッ
ファ１４１〜１４４を有している。ログバッファ１４１
〜１４４のサイズは均一ではなく、大きなサイズのもの
や小さなサイズのものがある。これらのログバッファ１
４１〜１４４には、メタキャッシュ１３０内で更新され
たメタデータの複製がログとして格納される。
【００９０】ログキャッシュ１４０とは別にログライト
バッファ１５０が設けられている。ログライトバッファ
１５０には、トランザクションの処理が終了した時点
で、ログバッファ１４１〜１４４内のログが転送され
る。
【００９１】この例では、複数のトランザクション１０
１〜１０３が並列動作している。このトランザクション
１０１〜１０３は、ファイルシステムオペレーションを
分割したものである。
【００９２】実際にＩ／Ｏを行うのは２つのデーモンで
あり、それぞれをメタライトデーモン１０４、ログライ
トデーモン１０５と呼ぶ。ログライトデーモン１０５が
ログをログ専用の二次記憶装置であるログボリューム１
２０に出力する。メタライトデーモン１０４は、ログボ
リューム１２０に対してログが出力されたことを確認し
た後、そのログに対応するメタデータをメタデータ専用
の二次記憶装置であるメタボリューム１１１〜１１３に
出力する。
【００９３】さらに、本発明のログ採取機能では、以下
のような特徴を有している。第１の特徴は、各メタデー
タに対応するメタデータ管理情報として、メタボリュー
ムを識別する情報が付加されていることである。これ
は、大規模ファイルシステムに対応するためのものであ
る。すなわち、複数の二次記憶装置がメタボリューム１
１１〜１１３として定義される場合に、メタキャッシュ
１３０上のメタデータ管理情報にそのメタデータが存在
するボリュームの情報を持たせている。
【００９４】図１２は、メタデータ管理情報を示す図で
ある。メタデータ管理情報には、「ボリューム番号」、
「メタデータ番号」、及び「メタデータポインタ」が登
録されている。「ボリューム番号」には、対応するメタ
データが存在するボリューム番号が登録されている。
「メタデータ番号」には、ボリューム毎におけるメタデ
ータ管理番号が登録されている。すなわち、システムが
認識するボリュームのデバイス番号とそのボリューム内
の位置から算定される数値によってメタデータが管理さ
れ、メタデータ自体がそれらの値を管理情報として保持
する。「メタデータポインタ」には、メタデータの実体
のある場所を指し示している。
【００９５】このようなメタデータ管理情報を有するメ
タデータの内容が更新されると、更新後のメタデータの
内容がログとしてログバッファに記録されるとともに、
メタデータ管理情報の内容がログに記録される。
【００９６】図１３は、ログバッファの形式を示す図で
ある。ログバッファには、「ＢＥＧＩＮマーク」、「ボ
リューム番号」、「メタデータ番号」、「メタデータ実
体」、及び「ＥＮＤマーク」の情報を含んでいる。
【００９７】ファイルシステムを復元する際には、ログ
内に記されているボリューム番号によって、そのログに
よって復元すべきメタデータの存在するメタボリューム
が認識される。これにより、従来技術のようにファイル
システム復元時にメタデータ番号からその存在すべきボ
リュームを決定するよりも速度向上が望め、システムダ
ウン後の大規模ファイルシステムにおいてもログ機構導
入によるファイルシステム復元時間の短縮が有効に機能
する。
【００９８】第２の特徴は、メタキャッシュ１３０内で
更新されたメタデータが、それぞれの管理構造にリンク
ポインタを持つことである。ログとしてログボリューム
１２０に記録されたメタデータはメタライトリストに繋
がれ、メタボリュームヘ反映が完了した時点でこのメタ
ライトリストから外される。さらに、ログとして記録さ
れているログボリューム１２０内の位置情報をも、メタ
ライトリスト内に持つ。このログボリューム内位置情報
をリストを辿って検索することによって、システムダウ
ン時に必要とされるログの範囲を特定することができ
る。そこで、ここから得られる有効範囲情報をログボリ
ューム１２０の特定位置に設けたボリューム管理情報１
２１内に記録する。有効範囲情報を記録し、ファイルシ
ステム復元時にそこに含まれるログのみをリプレイする
ことにより、ログボリューム全体を検索する必要がなく
なり、ログボリューム全体を読み込む必要のある、有効
範囲情報を記録しない従来の方式よりもファイルシステ
ムの復元時間をさらに短縮することができる。
【００９９】ところで、ログ機構はシーケンシャル性を
持ったディスクアクセスを行うことで、記録すべき内容
をヘッドシークすることなしにディスクヘ保存でき、デ
ィスクアクセス時間の短縮を図っている。ところが、本
手法を採用した場合、メタデータのメタボリューム反映
時、ログボリュームヘの書き出し時に、ログボリューム
の特定位置に有効範囲情報を書き出すこととなる。これ
ではシーク削減の意図が全く意味を成さない。
【０１００】そのため、本実施の形態ではある程度のイ
ンターバルを空けて、有効範囲情報は書き出すように工
夫した。変更がある度に、常に書き込まれるわけではな
いため有効範囲情報として保存されている情報には若干
の誤差が含まれてしまう。ファイルシステム復元時にそ
の誤差を吸収する必要がある。
【０１０１】図１４は、有効範囲を説明する図である。
図中において、「●」で示すのが、まだメタボリューム
に反映が終了しておらず、ファイルシステム復元に必要
なログを意味する。「○」で示すのは、メタボリューム
に反映が完了したことによって、ファイルシステム復元
時には利用しなくても良いログである。
【０１０２】従来のファイルシステムにおいて、ログを
用いたファイルシステム復元では、ログボリューム全体
を検索し，ログに記録されたシーケンス番号から、最古
のログを求め、たとえそれがメタボリュームに反映済み
の、利用しなくても良いログであっても利用して、ログ
ボリューム全体のログを用いていた。
【０１０３】本発明では、ある時点で有効範囲情報を書
き出した時の有効範囲が示されている。その後、有効範
囲を書き出さずに、メタボリュームヘの反映が進み、ま
た、別のトランザクションのログがログボリュームに書
き出されたことによって、実際の有効範囲と有効範囲情
報とはズレを生じている。この時点でシステムがダウン
し、ログを用いてファイルシステムを復元する場合に
は、多少のムダが生じるが、有効範囲情報が示す先頭位
置から、ログを利用する。利用すべきログの末端は有効
範囲情報以降の一定範囲を検索しなければならないが、
その検索は有効範囲情報を書き込むインターバルに依存
し、範囲が限られている。
【０１０４】第３の特徴は、ログに対してトランザクシ
ョン終了時にシーケンス番号を与え、その番号にはデー
タサイズが肥大化することを考慮に入れた上で、十分大
きいデータ型を適用することである。データ型の大きさ
は、コンピュータ自身の使用可能年数の間使い続けても
枯渇しない程度のサイズとする。例えば、システムの年
表記を４桁の十進数「最大９９９９」で表していた場
合、西暦１万年まで使用されることは想定されていな
い。その場合、西暦９９９９年まで使用可能なデータ型
とすれば、ログに対するシーケンス番号がオーバーフロ
ーして逆転することがないことを保証することができ、
それにより、ログボリューム全体をゼロクリアして初期
化する必要が生じない。具体的には、データ型を６４ビ
ット型とすれば、オーバーフローすることは現実にはあ
りえない（４万年ほど耐えられるものと思われる）。フ
ァイルシステム管理情報、各トランザクションのログ、
有効範囲情報にこのシーケンス番号を含め、ログボリュ
ームに記録する。このように、ログに与えるシーケンス
番号のデータ型に十分大きいものを適用することによ
り、通常の運用時にトランザクションが動作する毎にイ
ンクリメントしても、オーバーフローは現実には起こり
得ない。
【０１０５】さらに、スーパブロックと呼ばれるファイ
ルシステム全体の管理情報にこのシーケンス番号を含
め、正常なアンマウント処理時及びファイルシステム復
元時にスーパブロックに含まれるシーケンス番号を正し
く設定し、次回のマウント時にそこから得られる値を用
いる。これにより、シーケンス番号は必ず昇順となるこ
とが保証され、ファイルシステム復元時に新しいログを
古いものと取り違えないことが保証される。
【０１０６】シーケンス番号の順序性を保証することに
よって、ファイルシステム復元時にログボリュームをゼ
ロクリアしなくとも、常に正しいログを利用することが
可能となり、ファイルシステム復元時にログボリューム
全体をゼロクリアするのに比べ、大幅な時間短縮が可能
となる。
【０１０７】以上の理由により、ログの最大のメリット
であるファイルシステム復元の時間短縮がより一層有効
に機能することが可能となる。第４の特徴は、トランザ
クションによって更新されたメタデータが、そのメタデ
ータの属性に応じ、再度同一のトランザクションにおい
て更新される可能性のあるメタデータであった場合に
は、更新の時点ではログバッファにはコピーせず、リス
ト構造（トランスリスト）によって管理することであ
る。
【０１０８】そして、同一トランザクション内で複数回
更新されるメタデータとして、領域割当て管理情報をリ
スト構造で管理し、トランザクション進行中にはその中
途段階のログは採取しない。トランザクション終了時に
リスト構造を辿って、トランザクションの更新の最終状
態のみを一括してログとすることによって、ログの縮小
が図られ、それに伴いファイルシステム復元時間の短縮
が可能となる。
【０１０９】具体的には、メタキャッシュ１３０内のメ
タデータを管理する構造にトランスリストヘのリンクポ
インタを持たせることによって実現している。トランザ
クションによって更新されたメタデータは、ただ一回し
か更新されないことが分かっているメタデータである場
合には、その時点でログバッファヘコピーされるが、以
降もトランザクション進行中に更新される可能性がある
場合には、このリンクポインタを用いてリスト構造に繋
がれる。メタデータの更新可能性の有無は、トランザク
ションの種別で判断する。例えば、データ領域の空きな
どを管理するためのトランザクションでは、何度もメタ
データが更新される。
【０１１０】そして、トランザクションが終了する時に
このトランスリストを辿り、メタデータの最終形態をロ
グバッファヘコピーする。すると、結局はトランザクシ
ョンが同一メタデータを複数回更新しても、最終形態の
一回だけのログ採取で済まされる。
【０１１１】図１５は、ログ採取処理のフローチャート
である。この処理は、オペレーティングシステムを実行
するＣＰＵが行う処理である。以下、ＣＰＵがオペレー
ティングシステムを実行することにより実現する機能
を、単に「システム」ということとする。 ［Ｓ１］トランザクションの開始宣言を行う。 ［Ｓ２］ログ採取要求を行う。 ［Ｓ３］対象メタデータの更新可能性の有無を判断す
る。更新可能性があればステップＳ５に進み、そうでな
ければステップＳ４に進む。 ［Ｓ４］ログバッファへメタデータをコピーし、ステッ
プＳ２に進む。 ［Ｓ５］対象メタデータはトランスリストに繋がれてい
るか否かを判断する。トランスリストに繋がれていれば
ステップＳ７に進み、そうでなければステップＳ６に進
む。 ［Ｓ６］メタデータ毎にトランスリストに繋ぐ。 ［Ｓ７］トランザクションの処理が終了するか否かを判
断する。終了するのであればステップＳ８に進み、そう
でなければステップＳ２に進む。 ［Ｓ８］トランザクション終了宣言を行う。 ［Ｓ９］トランスリストを辿り、繋がれている最終形態
のメタデータをそれぞれログバッファへコピーする。
【０１１２】このようにして、トランザクションの更新
の最終状態のみを一括してログとして保存することがで
きる。第５の特徴は、メタボリュームの割当て管理情報
は獲得用として通常の割当て管理情報の複製を新たに設
けたことである。ここで、割り当て管理情報として、ビ
ットマップを例に挙げて説明する。
【０１１３】図１６は、メタボリュームの割り当て管理
状況を示す図である。割り当て管理情報１３１には、使
用されているメタデータを管理するためのビットマップ
１３１ａが用意されている。ビットマップ１３１ａは複
数のブロックに分けられている。そして各ブロックのビ
ットマップの各ビットが「０」か「１」かによって、対
応するメタデータが空いているか否かが示される。そし
て、ブロックに分けられたビットマップの１つの複製が
作られ、獲得用ビットマップ１３１ｂとされる。
【０１１４】獲得時には、通常のビットマップ操作と同
様に未割り当て状態の領域の検索が行われる。この時、
検索対象として用いるのは獲得用ビットマップ１３１ｂ
である。獲得用ビットマップ１３１ｂ内から未割り当て
状態の領域（ビットが立っていない）が見つかった時に
は、その獲得要求には見つかったビット番号を返す。そ
して、獲得用ビットマップ１３１ｂ及び、その複製元と
なったビットマップの対応ビットを立てる。一方、獲得
用ビットマップ１３１ｂ内から未割り当て状態の領域が
見つからなかった時には、別のブロックのビットマップ
の複製を生成し、新たな獲得用ビットマップ１３１ｃと
する。
【０１１５】図１７は、ビットマップによるメタデータ
獲得処理を示すフローチャートである。この処理は、シ
ステムが行う処理である。 ［Ｓ１１］獲得要求を発行する。 ［Ｓ１２］獲得用ビットマップに空きがあるか否かを判
断する。空きがあればステップＳ２０に進み、そうでな
ければステップＳ１３に進む。 ［Ｓ１３］メモリ（メタキャッシュ１３０）上のビット
マップに「FreeDirty」フラグが立てられていないビッ
トマップが存在するか否かを判断する。存在すればステ
ップＳ１４に進み、存在しなければステップＳ１６に進
む。ここで「FreeDirty」フラグとは、一回以上の解放
処理が対象ビットマップに対してなされたことを意味す
る。 ［Ｓ１４］「FreeDirty」フラグが立てられていないビ
ットマップの中で、空きのあるものがあるか否かを判断
する。そのようなビットマップがあればステップＳ１５
に進み、そうでなければステップＳ１６に進む。 ［Ｓ１５］「FreeDirty」フラグが立てられておらず、
空きのあるビットマップの複製を、獲得用ビットマップ
に作成する。その後、ステップＳ２０に進む。 ［Ｓ１６］メタボリューム１１１〜１１３上のビットマ
ップに空きがあるか否かを判断する。空きのあるビット
マップがあればステップＳ１７に進み、そうでなければ
ステップＳ１８に進む。 ［Ｓ１７］メタボリューム１１１〜１１３上の空きのビ
ットマップをメモリ（メタキャッシュ１３０）上に読み
込み、ステップＳ１５に進む。 ［Ｓ１８］メモリ（メタキャッシュ１３０）上のビット
マップに「FreeDirty」フラグが立てられたビットマッ
プが存在するか否かを判断する。存在すればステップＳ
１９に進み、存在しなければ、獲得不可能と判断し処理
を終了する。 ［Ｓ１９］「FreeDirty」フラグが立てられたビットマ
ップをメタボリュームに反映し、「clean」状態にす
る。ここで「clean」状態とは、獲得、解放の処理が全
く行われていない状態を示す。その後、ステップＳ１３
に進む。 ［Ｓ２０］獲得用ビットマップのビットを立てる。 ［Ｓ２１］複製元ビットマップの同一ビットを立てる。 ［Ｓ２２］複製元ビットマップに「AllocDirty」フラグ
を立てる。ここで、「AllocDirty」フラグとは、対象ビ
ットマップから一回以上の獲得処理によって更新がなさ
れた場合に、そのビットマップの管理構造体内のフラグ
に立てる値である。「AllocDirty」フラグや「FreeDirt
y」フラグが立ったビットマップはログ採取対象であ
る。メタボリュームに反映された時にこれらのフラグは
落とされ、「clean」状態となる。
【０１１６】このようにして、空きのビットマップを獲
得できる。解放時にも、通常のビットマップ操作と同様
に、要求された領域が対応するビットの算出がまず行わ
れるが、対応するビットを落とす操作は、対象のビット
マップに対してのみ行い、仮にその対象ビットマップの
複製が獲得用ビットマップとして存在する場合にも、そ
の獲得用ビットマップに対しては行わない。
【０１１７】図１８は、解放処理のフローチャートであ
る。この処理は、システムが行う。 ［Ｓ３１］解放要求を出す。 ［Ｓ３２］対象ビットマップがメモリ（メタキャッシュ
１３０）上にあるか否かを判断する。対象ビットマップ
があればステップＳ３４に進み、そうでなければステッ
プＳ３３に進む。 ［Ｓ３３］メタボリューム１１１〜１１３上の対象ビッ
トマップをメモリ（メタキャッシュ１３０）上に読み込
む。 ［Ｓ３４］対象ビットマップの対応するビットを落と
す。 ［Ｓ３５］対象ビットマップに「FreeDirty」フラグを
立てる。
【０１１８】この一見複雑に見える作業によって、解放
した領域を即座に別の用途に利用してしまうことを回避
することが可能となり、システムダウン時に中途までし
か終了していなかった解放トランザクションが解放した
はずである領域は、解放される直前の状態のまま保全さ
れることが保証できる。
【０１１９】例えば、Ａというトランザクションが解放
処理、Ｂというトランザクションが獲得処理を行う場合
を考える。ここで、トランザクションＡの解放処理はト
ランザクションＢの獲得処理よりも先に行われ、かつ、
トランザクションＡはトランザクションＢよりも後に終
わる場合を例に挙げる。
【０１２０】図１９は、トランザクションの処理の開始
と終了の状況を示す図である。この図において、各トラ
ンザクションは「ＢＥＧＩＮ」で始まり、「ＥＮＤ」で
終わることを意味し、トランザクションの「○」が解放
処理を、「●」が獲得処理を意味する。
【０１２１】上図のように、トランザクションＡの解放
処理がトランザクションＢの獲得処理よりも先に行わ
れ、かつ、トランザクションＢのほうがトランザクショ
ンＡよりも先に終了した場合に従来のログ採取方式では
問題が生ずることは既に述べた。
【０１２２】本発明が提案する手法を用いれば、トラン
ザクションＢが獲得する領域がトランザクションＡが解
放した領域となることは基本的にはなく、領域枯渇状態
に近く、どうしてもこの領域を獲得せねばならない時に
は、一旦、該当ビットマップをメタボリュームに反映し
た後、獲得処理が行われる。これにより、ファイルシス
テム復元時に必要とされる、メタボリュームに未反映な
メタデータを対象とするログを用いた復元では、管理情
報上、二重獲得と見えるようなログは残り得ない。
【０１２３】また、トランザクションＢのログにはトラ
ンザクションＡの解放処理が記録されないため、トラン
ザクションＢのログよりも後に復元に用いるトランザク
ションＡのログによって、トランザクションＢが獲得し
た領域を変更されることもありえない。
【０１２４】第６の特徴は、前述のようにログ機構の導
入にあたり、獲得・解放操作のログとして、その獲得・
解放した対象の情報（このビットを立てた・落した）の
みを記録することである。これによって、複数の獲得・
解放要求に対して、要求の発生後、トランザクションの
終了時点までをシリアライズすることなくログ管理で
き、かつログ採取量は減少し、複数トランザクション動
作による変更をメタボリュームヘ反映する回数をも減少
させることができる。
【０１２５】第７の特徴は、ログキャッシュ１４０を複
数のログバッファで管理し、この時、いくつかの異なる
サイズとすることである。ログキャッシュ１４０を分割
して複数のログバッファとして管理することによって、
トランザクションの独立性を確立することが容易となる
とともに、有限なメモリ空間を有効に活用することが可
能となる。
【０１２６】まず、トランザクションがメタデータを更
新するより以前に、自分がメタデータを更新する旨、シ
ステムに宣言する。この時、トランザクションの種別よ
り予測されるログ採取情報に応じて、最適なサイズのロ
グバッファがシステムより与えられ、トランザクション
進行に伴い蓄積されるログはここへ溜められることとな
る。上記第６の特徴で説明した手法に加え、トランザク
ション毎に異なるログバッファを用いることによって、
複数のトランザクション更新の混じらない、純粋なログ
として残すことが可能である。
【０１２７】第８の特徴は、上記第７の特徴で説明した
手法に加え、トランザクションの開始時に予測したログ
採取量よりも多くのログを採取しなければならなかった
場合に、与えられたログバッファから、さらに大きいロ
グバッファへ移行することである。システムの状況に応
じて、トランザクションによって残されるログのサイズ
は変動し、その差異を複雑な処理を必要とせず、かつ、
有限なメモリ空間を有効に活用して吸収することが可能
である。
【０１２８】第９の特徴は、ログバッファに入りきらな
い場合には、ログボリュームへ中間ログを書き出すとと
もに、中間ログを書き出すことによる矛盾の発生を防止
する機能を備えたことである。
【０１２９】ログボリュームに対するＩ／Ｏ発行を減少
させるために、ログライトバッファと呼ぶ二次キャッシ
ュ領域を設けている。終了したトランザクションのログ
は、ログバッファからこのログライトバッファヘ移さ
れ、適時にログライトデーモン１０５によってログボリ
ュームヘ書き出される。この適時とは、負荷が低い場合
には一定の周期で良いが、トランザクションによるメタ
データの更新量が多く、最大のログバッファでも収まら
ない場合などには強制的なＩ／Ｏ発行が必要とされる。
このような場合において、中途の段階でのログの出力で
は、まだ更新されていない（かもしれない）メタデータ
を含めた書き出しを行うことがファイルシステムの整合
性を保つためには必要である。
【０１３０】このように有限なメモリ空間を有効活用す
ることを考慮した上で、ログバッファ内に収まりきらな
いログをトランザクション途中で出力する時に、残され
るログによって復元されるファイルシステムの整合性を
正当なものとするための手法を提案している。
【０１３１】ファイルシステムに対する負荷がそれほど
高くない場合には、ログのログボリュームに対するＩ／
Ｏを極力少なくするために事前に与えられた周期に応じ
て定期的にデーモンによって行われる。しかし、ログバ
ッファが枯渇し、以降のトランザクション進行で溜めら
れるログが収まらないと判断された時、部分的なログと
して、この時点のログをログボリュームヘ出力する。こ
の時、まだ更新されていない情報をもログに出力する。
例えばファイルを追加ライトするトランザクションの場
合は、部分的なログを出力する時点でのファイルサイズ
や時刻情報を合わせてログに記録する。これによって、
部分的であるはずのこのログを、ファイルシステム復元
時には完結した１つのトランザクションのログと同等に
扱うことが可能となり、ファイルシステム復元時に複雑
な考慮の必要なしに、望ましい状態にファイルシステム
を復元することが可能となる。
【０１３２】図２０は、ログバッファへのログの格納状
況を示す図である。この例では、２種類のサイズのログ
バッファ１４１〜１４６が設けられている。ログバッフ
ァ１４１〜１４５は通常のサイズであり、ログバッファ
１４６が大きなサイズである。
【０１３３】また、ログバッファ１４１〜１４６を管理
するためのログバッファ管理テーブル１４８，１４９が
設けられている。ログバッファ管理テーブル１４８は、
ログバッファ１４１〜１４６に対応するフラグビットを
有している。そして、使用されているログバッファに対
応するフラグビットの値が「１」に設定され、未使用の
ログバッファに対応するフラグビットの値は「０」に設
定されている。同様に、大きいサイズのログバッファ１
４６に対応するログバッファ管理テーブル１４９もフラ
グビットを有しており、そのフラグビットの値によっ
て、ログバッファ１４６が使用されているか否かを管理
している。
【０１３４】ログキャッシュ１４０内の各ログバッファ
１４１〜１４５のうち、ログバッファ１４３とログバッ
ファ１４５とが現在利用中であることを意味するため
に、「●▲」などの記号を用いた。ここで、ログバッフ
ァ１４５には多くのログが溜まっており、既に満杯の状
態となっている。このように通常のサイズのログバッフ
ァ１４１〜１４５では容量が足りなくなった際には、そ
のログを大きいサイズのログバッファ１４６に移動す
る。そして、トランザクションが継続している間は、更
新されたメタデータの内容を、随時ログバッファに格納
していく。ここで、トランザクションが終了したら、そ
のトランザクションに対応するログバッファの内容をロ
グライトバッファ１５０へ転送する。
【０１３５】ログライトバッファ１５０には、複数のバ
ッファ１５１，１５２が設けられており、それらのバッ
ファ１５１，１５２にログが書き込まれる。ログライト
バッファ１５０内のログは、ログライトデーモン１０５
によって随時ログボリュームに書き込まれる。
【０１３６】図２１は、ログ採取手順を示すフローチャ
ートである。これはシステムが行う処理である。 ［Ｓ４１］BEGIN宣言を行う。 ［Ｓ４２］ログバッファの予約をする。 ［Ｓ４３］ログ採取要求を行う。 ［Ｓ４４］現在のログバッファに今回のログが収まるか
否かを判断する。収まるのであればステップＳ５１に進
み、収まらないのであればステップＳ４５に進む。 ［Ｓ４５］現在のログバッファより大きいログバッファ
が存在するか否かを判断する。存在すればステップＳ４
６に進み、そうでなければステップＳ４７に進む。 ［Ｓ４６］現在のバッファから大きいバッファへ内容を
コピーし、ステップＳ４４に進む。 ［Ｓ４７］トランザクションに与えられたパラメタをロ
グ採取する。 ［Ｓ４８］現時点のファイル状態を正しく表す管理情報
をログ採取する。 ［Ｓ４９］現在の中途段階のログをログライトデーモン
１０５に書き出させる。 ［Ｓ５０］現在のログバッファをクリアする。 ［Ｓ５１］ログを採取する。 ［Ｓ５２］ログ採取要求を終了する。 ［Ｓ５３］ＥＮＤ宣言があるか否かを判断する。END宣
言があればステップＳ５４に進み、そうでなければステ
ップＳ４３に進む。 ［Ｓ５４］END宣言を行い、処理を終了する。
【０１３７】第１０の特徴は、トランザクションが完了
する前に、システムダウンが発生した場合に備え、分割
して出力するログにはトランザクションに与えられたパ
ラメタを含め、ファイルシステム復元時にそのパラメタ
を元に、再度トランザクションを実行することである。
【０１３８】さらに、この部分的なログにトランザクシ
ョンに与えられたパラメタを記録し、ファイルシステム
復元時にそれを用いて、通常のログだけでは中途で終わ
った状態までしか復元できないファイルを、トランザク
ションが終了した状態にまでファイルシステムに反映す
ることが可能となる。
【０１３９】図２２は、ファイルシステム復元処理を示
すフローチャートである。これはシステムが行う処理で
ある。 ［Ｓ６１］システムダウン等が発生する。 ［Ｓ６２］ファイルシステムの異常を検知する。
【０１４０】以降、ファイルシステム復元処理を行う。 ［Ｓ６３］ログ開始マークを検出する。 ［Ｓ６４］ログ開始マークに対応するログ終了マークが
存在するか否かを判断する。ログ終了マークが存在すれ
ばステップＳ６５に進み、ログ終了マークが存在しなけ
ればステップＳ６６に進む。 ［Ｓ６５］開始マークから終了マークまでのログを用い
て復元処理を実行する。その後、ステップＳ６３に進
む。 ［Ｓ６６］対象トランザクションが以前のログだけで完
結するか否かを判断する。完結するのであれば復元処理
を終了し、完結しないのであればステップＳ６７に進
む。 ［Ｓ６７］ログに記録されたパラメタを読み込む。 ［Ｓ６８］トランザクションとして行いたかった処理を
理解する。 ［Ｓ６９］ファイルに対して直接処理を再実行する。そ
の後、復元処理を終了する。
【０１４１】これにより、オペレーションのセマンティ
クスを保証したファイルシステムの復元が可能となり、
従来技術では完全に元に戻す、または完全に再実行する
ことが不可能であったトランザクションを、完全に再実
行することによってファイルの整合性をも回復すること
が可能となる。
【０１４２】第１１の特徴は、メタデータを更新するト
ランザクションが更新処理を行う前に、その旨をシステ
ムに対し宣言することである。さらに、システムは宣言
を受け入れるか否かを判断する機構を持つことである。
ここでは、以下の条件の場合には新規のトランザクショ
ンの受け入れを拒否し、拒否されたトランザクションは
再度認可が下りるまで待合わせなければならない。 ・メタキャッシュ１３０がフルに近い状態にある場合。 ・トランザクションの多重度が、システムで規定された
値を既に越えていた場合。 ・ログボリュームに残されたログの大部分が有効なログ
状態である場合。
【０１４３】これらの場合に、ファイルシステムが新規
トランザクションの受け入れを拒否し、トランザクショ
ンの多重度を制限することによって、結果としてダーテ
ィなメタデータの数を制限することが可能となり、メタ
キャッシュ１３０の空き領域枯渇などを要因とするハン
グアップ状態に陥ることを回避することが可能となる。
特に、分割ログとしてログ採取しなければならないトラ
ンザクションが動作中に、新規トランザクションの開始
を拒否することは、システムの状態を正常に維持する上
で効果が高い。
【０１４４】第１２の特徴は、新規トランザクションの
受け入れ拒否の機構をログボリューム内の有効ログの割
合に応じて適用することにより、単一の、多数のメタデ
ータを更新するトランザクションのみならず複数のトラ
ンザクションが更新したメタデータによって空き領域の
減少に伴うハングアップ状態をも回避することである。
【０１４５】以下に、第１１の特徴と第１２の特徴とを
含むトランザクションの受け入れ処理について説明す
る。図２３は、新規トランザクションの受け入れ許否判
定処理を示すフローチャートである。 ［Ｓ７１］トランザクションを行うプロセス（以下、単
にトランザクションという）が、トランザクション処理
を開始する。 ［Ｓ７２］「BEGIN」宣言を行う。この際、オペレーテ
ィングシステム（以下、単に「システム」という）に対
して問い合わせを行う。 ［Ｓ７３］トランザクションは、システムからの回答待
ち状態となる。システムより「ＯＫ」の回答を受け取っ
たらステップＳ８２に進む。 ［Ｓ７４］トランザクションからの問い合わせを受けた
システムが、パラメタの評価を開始する。 ［Ｓ７５］システムは、既に多重度が規定値より上であ
るか否かを判断する。多重度が規定値より上であれば
「ＮＧ」としてステップＳ８１に進み、そうでなければ
「ＯＫ」としてステップＳ７６に進む。 ［Ｓ７６］システムは、現在サブトランザクションが動
作中であるか否かを判断する。サブトランザクションが
動作中であれば「ＮＧ」としてステップＳ８１に進み、
そうでなければ「ＯＫ」としてステップＳ７７に進む。
ここでサブトランザクションとは、ログを複数に分割し
て格納する場合に、１つのログバッファにログを格納で
きるような処理単位に分割されたトランザクションであ
る。 ［Ｓ７７］システムは、メタキャッシュ１３０に十分な
空きがあるか否かを判断する。十分な空きがなければ
「ＮＧ」としてステップＳ７９に進み、十分な空きがあ
れば「ＯＫ」としてステップＳ７８に進む。 ［Ｓ７８］システムは、ログボリュームに上書き可能領
域が少ないか否かを判断する。上書き可能領域が十分に
なければ「ＮＧ」としてステップＳ７９に進み、十分な
上書き可能領域があれば「ＯＫ」としてトランザクショ
ンに対して「ＯＫ」の回答を返す。 ［Ｓ７９］システムは、ログライトデーモン１０５を起
動する。 ［Ｓ８０］システムは、メタライトデーモン１０４を起
動する。 ［Ｓ８１］システムは、ＮＧ条件が解消されるまでスリ
ープ状態で待つ。ＮＧ条件が解消されたら、ステップＳ
７５に進む。 ［Ｓ８２］トランザクションは、システムからの「Ｏ
Ｋ」の回答を受け取ったら、多重度インクリメント処理
を行う。 ［Ｓ８３］トランザクションは、「BEGIN」処理を終了
する。 ［Ｓ８４］トランザクションは、処理に応じて、メタデ
ータをキャッシュに読み込み、その度に空き量をデクリ
メントする。分割ログ化するなら他トランザクションの
開始を拒否するようにシステムに依頼する。 ［Ｓ８５］トランザクションは、「END宣言」を行う。 ［Ｓ８６］トランザクションは、多重度をデクリメント
する。 ［Ｓ８７］トランザクションは、必要に応じてログ採取
を繰り返した後、自己のトランザクション処理を終了す
る。
【０１４６】次に、本発明を適用したシステムの具体的
な処理内容について説明する。本発明の全ての特徴を備
えたシステムにおけるログ採取手順は以下のようにな
る。ファイルシステムオペレーションを分割したトラン
ザクションはメタデータを更新するより前に、自分がこ
れからメタデータを更新する旨を宣言する（ＢＥＧＩ
Ｎ）。ＢＥＧＩＮ時にトランザクションに対し、独立し
たログバッファが割当てられる。この時、既にトランザ
クションの並列動作数が非常に多かったりメタキャッシ
ュ１３０域の利用率が高い場合には、システムによって
ＢＥＧＩＮ宣言が拒否される。ＢＥＧＩＮ宣言を拒否さ
れたトランザクションはその拒否理由が解消されるま
で、待ち合わせなければならない。
【０１４７】更新が完了したメタデータは、ＢＥＧＩＮ
時に割り当てられたログバッファヘコピーされる。それ
と同時にメタデータ種類に応じたリストへ繋がれる。更
新すべき全てのメタデータを更新し終わったトランザク
ションは、そこで完了を宣言する（ＥＮＤ）。ＥＮＤ時
には、これまで溜めたログバッファの内容をログ専用の
二次キャッシュであるログライトバッファヘ移動し、さ
らに、まだログバッファヘコピーされていなかったメタ
データをログライトバッファヘコピーする。
【０１４８】また、ＥＮＤ時にメタデータの種類に応じ
て繋がれていたリストから、そのトランザクションが更
新した全てのメタデータを「ログ待ちリスト」へ繋ぎ替
える。
【０１４９】以上で非同期要求のトランザクションは終
了することができる。トランザクションが同期要求であ
った場合には、ログを書き出すまで待ち合わせなければ
ならない。
【０１５０】ログの書き出しは独立したデーモン（ログ
ライトデーモン１０５）が行う。このデーモンの起動契
機は、同期要求トランザクションによる起動要求（ｗａ
ｋｅｕｐ）、メタキャッシュ１３０の空き状態監視機構
による起動要求（ｗａｋｅｕｐ）、及びタイマである。
【０１５１】起動したログライトデーモン１０５は複数
のトランザクションのログがまとめられたログライトバ
ッファを１つのＩ／Ｏとして発行する。そして、ログ待
ちリストから「書き出しリスト」ヘメタデータを移動す
る。
【０１５２】メタボリュームヘＩ／Ｏを発行するのは、
メタライトデーモン１０４の役割である。メタライトデ
ーモン１０４は書き出しリストに繋がれたメタデータを
順に非同期ライトによってメタボリュームに反映する。
メタライトデーモン１０４の起動契機は、ログバッファ
の空きが少なくなった時、ログボリュームの空きが少な
くなった時、及びタイマである。
【０１５３】以上が、メタデータを更新するトランザク
ションの開始から、更新されたメタデータがメタボリュ
ームに反映されるまでの大まかな流れである。以降に、
ログの採取とそのディスク反映手法、そして、メタデー
タのディスク反映の処理について詳細に説明する。 （１）ログの構造 （１．１）ログボリューム ログボリュームに格納される情報は、以下のような情報
である。
【０１５４】ログボリュームにはスーパブロック、ボリ
ューム管理情報が先頭にある。その次にログの有効範囲
を示す構造体を記録する。構造体は以下のメンバを持
つ。 ・有効ログ先頭のログボリューム内オフセット ・有効ログ先頭のログシーケンス番号 ・有効ログ末尾のログボリューム内オフセット ・有効ログ末尾のログシーケンス番号 ただし注意しなければならないのは、ここで先頭・末尾
と言っているのは、真の値ではない可能性があることを
リプレイ時に考慮しなければならない点である。なぜな
ら、ログはボリュームをシーケンシャルアクセスするこ
とによってシーク時間の短縮を計っているが、このよう
にボリュームの一部へ毎回アクセスしたのでは、そのシ
ーケンシャル性が損なわれてしまう。そのために、ログ
の書き出し毎にはこの有効範囲の書き出しは行わず、数
回に一回、書き出している。
【０１５５】これにより、上記構造体に収められたオフ
セットは正確ではないためにリプレイ時に検索が必要で
はある。しかしながら、全体を検索するよりも大幅に検
索量が減るため、利点は保持できるものと考える。
【０１５６】上記以外は、全て、メタデータの更新履歴
によって構成される。 （１．２）ログブロックの基本構造 ログボリューム１２０内に残されたログ（メタデータの
更新情報）は基本的にはトランザクション単位である。
これをログブロックと呼ぶ。しかし、キャッシュ域フル
などによって、１つのトランザクションを一度にまとめ
ることができない場合は複数の分割ログに分ける。この
分割ログをサブトランザクションログと呼ぶ。
【０１５７】サブトランザクションログをリプレイする
ことによって、ファイルシステムの整合性が保てるよ
う、その内容は工夫されている。しかしながら、トラン
ザクションの途中までのサブトランザクションをリプレ
イしたのでは、トランザクション全体が終わっていない
ことから、ファイルシステムとしての整合性が保てて
も、ファイルの中身は異常であるという状態に陥ってし
まうことが考えられる。
【０１５８】この状態を回避するために、そのサブトラ
ンザクションに別れたトランザクションがどのようなオ
ペレーションであったかをログに採取する（オペレーシ
ョンログ）。ログリプレイ時には、サブトランザクショ
ンをリプレイした後、オペレーションログをリプレイヤ
が再実行することによって、トランザクション全体が終
わった状態とすることが可能である。
【０１５９】サブトランザクション化する可能性のある
トランザクションは全体終了時に「終わったこと」をロ
グに記録し（最終ＥＮＤマーク）、リプレイヤはその有
無を調べてオペレーションログの実行を判断する。 （１．３）ログの採取形式 メタデータの更新情報は該当するメタデータの管理構造
単位で採取する。また、メタボリュームの管理構造であ
るビットマップはその更新部分だけのログ採取とする、
スーパブロックについては特殊であり、データ空き容量
についてのみログ採取を行う。 （１．３．１）ｉｎｏｄｅ、Ｖデータ、空き管理情報 ファイルの管理情報であるｉノード、Ｖデータと呼ぶデ
ィレクトリやシンボリックリンクデータや空き管理情報
のメタデータ本体は、それらのＩ／Ｏ単位（ブロック単
位）でのログ採取を行う。
【０１６０】これは、ファイルシステム整合性チェック
処理であるｆｓｃｋによるログリプレイ時の処理を簡略
化することを意識している。変更された部分だけをログ
採取した場合、ログリプレイ時には、該当ブロックの算
定→読み込み→変更部分の更新→再度書き込み、とステ
ップが増えてしまう。しかし、ブロック全体のログ採取
によって、リプレイ時にはメタボリュームにログ情報を
上書きするだけでよい。
【０１６１】ｉノード本体やディレクトリブロックなど
のＶデータは、更新中はファイルのロックで保護されて
いる。しかしながら、空き管理情報についてはファイル
のロックでは保護されない。そのため、トランザクショ
ン途中で他トランザクションによって更新され、そのト
ランザクションが追い越して先に終わってしまうと、ロ
グには古い情報が後に残されてしまい、リプレイすると
ファイルシステムに不整合が生じてしまう。
【０１６２】そのため、空き管理部については、ここで
は更新するトランザクションが並行動作しないことを保
証することによって実質的な排他制御を行い、他のメタ
データと同じ採取形式とした。 （１．３．２）ビットマップ メタデータの割り当て状況を管理するビットマップも空
き管理部と同様にファイルのロックで保護されていな
い。そのため、ビットマップ全体のログ採取を行うと、
そのログには複数のトランザクションによる更新が含ま
れてしまう可能性がある。特に、トランザクションの追
い越しが発生すると、新しいはずのログによって、ビッ
トマップの情報が古く書き戻されてしまうことが考えら
れる。
【０１６３】そこで、ビットマップのログ採取は更新部
分だけとする。更新部分とは、あるビットが０になっ
た、あるいは１になったと記録するだけである。それに
より、トランザクションが並行動作してもそれぞれのト
ランザクションが更新した内容のみがログに残されるた
め、メタデータの後退は起こり得ない。
【０１６４】注意すべきは、ある領域を解放（「１→
０」）した後、他トランザクションがそこを獲得（「０
→１」）した場合である。トランザクションの追い越し
が発生すると、ログリプレイによって獲得した領域を解
放してしまう。
【０１６５】これについては、アロケート用ビットマッ
プを１つ定め、複製を用いて操作を行うことによって回
避する。 （１．４）ログの記録構造 （１．４．１）一般ログログ 有効状態であっても、ある程度の複数スレッドが同
時に進行することを許す。これは性能要件より必須であ
る。しかし、ログボリューム内のログは前述の通り、ト
ランザクション毎に保存する。１つのトランザクション
結果をログに記録する際、ログは以下のパーツで構成す
る。 １）ＢＥＧＩＮマーク ２）ヘッダ ３）更新内容 （２）＋３）の繰り返し） ４）ＥＮＤマーク これを以下、ログブロックと呼ぶ。ログブロックはログ
ボリュームの物理ブロック境界から始まるが、その終わ
りは物理ブロック境界であるとは限らない。 １）ＢＥＧＩＮマーク トランザクションの開始時に作成される情報であり、以
下の内容を含む。 ・マジックワード ・トランザクションタイプ ・ログシーケンス番号 ・ログブロックサイズ マジックワード：１つのトランザクションが始まったこ
とを示すマジックワードを埋め込む。
【０１６６】トランザクションタイプ：ＢＥＧＩＮマー
クにトランザクションのタイプ（種類）を埋め込むこと
によって、その後ろの更新情報に含まれる内容の概要を
事前に知ることが可能。
【０１６７】ログシーケンス番号：ログに記録されたト
ランザクション毎にインクリメントされる数値。このカ
ウンタが最小のログブロックがそのログボリューム内で
最も古いトランザクションであることを示す。カウンタ
は６４ビット型とし、オーバーフローすることは現実に
はありえない（４万年ほど耐えられるものと思われ
る）。ログリプレイ時に、ログボリュームをゼロクリア
することにより、再度０から開始することも考えられる
が、リプレイ時間の短縮を考慮し、利用したログの最後
のシーケンス番号より昇順に採番することによりゼロク
リアを回避する。
【０１６８】ログブロックサイズ：ログブロックのＥＮ
Ｄマークまでのサイズを記録する。ＢＥＧＩＮマークの
先頭からＥＮＤマークの先頭までのサイズである。リプ
レイ時にはＢＥＧＩＮマークの先頭からこのサイズだけ
移動し、ＥＮＤマークの情報を参照して、ログの有効性
を判定する。 ２）ヘッダ 更新されたメタデータについて、その保管位置を特定す
るための情報であり、以下のメンバによって構成され
る。 ・メタデータタイプ ・メタボリューム番号 ・ボリュームローカルメタデータ番号 メタデータタイプ：更新情報の後方にあるメタデータ更
新内容が何のメタデータであるのかを特定するために用
いられ、リプレイヤはここから更新内容のサイズを判断
する。
【０１６９】メタボリューム番号：メタデータ管理で用
いているメタボリューム毎の番号を記録する。リプレイ
時には、この番号から書き戻すメタボリュームを決定す
る。 ボリュームローカルメタデータ番号：メタデータ管理で
用いている、メタボリューム毎、メタデータ毎に０から
始まる値を記録する。リプレイ時には、この番号からメ
タボリューム内のブロック位置に変換し、更新内容を書
き戻す。これはブロック位置変換を削減することによる
ログ採取の高速化が狙いである。対象がビットマップで
ある場合には、変更されたビットが該当するメタデータ
本体のメタデータ番号を記載する（ビットマップ番号で
はない）。 ３）更新内容 メタデータ本体の場合には、更新内容が含まれるブロッ
ク（それぞれのメタデータの管理単位）である。例え
ば、ディレクトリブロックが更新された場合には１０２
４バイトのディレクトリブロック全体である。
【０１７０】ビットマップの場合には、全体ではなく、
ここには「０→１」または「１→０」という情報だけ記
録する。リプレイ時にはヘッダから該当するビットマッ
プを判定し、それを読み込み、ここの内容から該当ビッ
トを変更して書き戻す。 ４）ＥＮＤマーク ＢＥＧＩＮマークに対応するマジックワード、ログシー
ケンス番号、ログブロックサイズを記録する。
【０１７１】ＥＮＤマークがマジックワードとログ番号
だけでは、メタデータの内容によってはそれが偽りのＥ
ＮＤマークとして見えてしまい、リプレイの時に処理を
誤る可能性がある。これを回避するために、ＥＮＤマー
クは固有形式（メタデータを誤認することのない形式）
としなければならない。
【０１７２】ＢＥＧＩＮマークを固有形式としないの
は、ＢＥＧＩＮマークだけ書き出された時点で、システ
ムダウンした場合を考慮し、いずれにせよＥＮＤマーク
の識別ができなければならないからである。
【０１７３】固有形式とするために、固有の数値を６４
バイト分続ける。これにより、全てのメタデータがＥＮ
Ｄマークに化けることはなくなる。これに続けて、マジ
ックワード、カウンタ（ログ番号）、ログブロックサイ
ズを記録する。以降、ブロック境界まで、上記数値を埋
める。ＢＥＧＩＮマークに対応したＥＮＤマークを見つ
けることができないログ情報はリプレイしてはならない
（ログ書き出し途中にシステムが異常終了したことを意
味する）。 （１．４．２）巨大トランザクションのログ トランザクションが多くのメタデータを更新する場合に
は、ログバッファサイズ、ログボリュームサイズが有限
であることから、複数のサブトランザクションログに分
割する。サブトランザクションログはそれだけのリプレ
イによって、ファイルシステムの整合性は保たれる。し
かし、トランザクション全体のサブトランザクションロ
グをリプレイしなければ、ファイルの整合性が保てな
い。そのため、サブトランザクション途中でのシステム
ダウンを考慮し、オペレーションログを内部に含む。 １）ＢＥＧＩＮマーク ２）オペレーションログ ３）ヘッダ ４）更新内容 （３）＋４）の繰り返し） ５）ＥＮＤマーク （１）〜５）の繰り返し） （５’）最終ＥＮＤマーク） １）ＢＥＧＩＮマーク 一般ログのＢＥＧＩＮマークと同じ。ただし、サブトラ
ンザクションログとなりうるトランザクションは、書き
込みや削除など、データ領域を触るものや、領域管理に
関わるものに限定される。
【０１７４】これらのトランザクションがＢＥＧＩＮマ
ーク内で設定されていたら、そのログはサブトランザク
ション化している可能性があり、必すオペレーションロ
グが続いている（たとえ単一のサブトランザクションロ
グで構成されていても）。 ２）オペレーションログ サブトランザクション化したトランザクション（関数）
に与えられた引数をオペレーションログとして保存す
る。巨大トランザクションを対象としたＢＥＧＩＮマー
クの直後には必ずオペレーションログを配置する。オペ
レーションログは、最初にトランザクションヘ渡された
情報（このファイルをこれだけのサイズトランケートす
るとか、このファイルをこれだけアペンドライトするな
ど）である。
【０１７５】リプレイ時には、リプレイヤがファイルシ
ステムを直接操作して、ここで残されたオペレーション
ログを実行しなければならない。オペレーションログは
以下のメンバで構成される。 ・パラメタ１ ・パラメタ２ ・・・ リプレイヤはＢＥＧＩＮマーク内のトランザクションタ
イプを見ることによって、オペレーションログ部分に並
ぶパラメタ群のサイズ及び内容を知ることができる。 ３）ヘッダ 一般ログのヘッダと同じ。 ４）更新内容 一般ログの更新内容と同じ。 ５）５’）ＥＮＤマーク、最終ＥＮＤマーク 一般ログのＥＮＤマークと同じ意味合いを持ち、ＢＥＧ
ＩＮマークに対応するＥＮＤマークあるいは最終ＥＮＤ
マークが見つからない場合には、ＢＥＧＩＮマーク以降
の更新内容をリプレイしてはならない。
【０１７６】巨大トランザクションがサブトランザクシ
ョンに分割されず、単一のログブロックのみの場合に
は、ＥＮＤマーク部分には最終ＥＮＤマークが書き出さ
れる。複数のサブトランザクションログに分かれている
場合には、最後のログブロックだけ、ＥＮＤマークが最
終ＥＮＤマークに化ける（最後以外のログブロックには
通常のＥＮＤマークが書かれている）。
【０１７７】ＥＮＤマークは一般ログのＥＮＤマークと
同一であり固有数値６４バイト、マジックワード、カウ
ンタ（ログ番号）、ログブロックサイズが記録されてお
り、ブロック境界まで固有数値が埋まる。
【０１７８】最終ＥＮＤマークとＥＮＤマークの差は、
マジックワードのみである。最終ＥＮＤマークがトラン
ザクション全体の終了を表すことから、とても巨大なト
ランザクションが多くのサブトランザクションログに分
割されている場合には、全ての処理が完了する時にこの
最終ＥＮＤマークを出力する。すなわち、巨大トランザ
クションとして定義されるトランザクションについて、
通常のＥＮＤマークで終わるログブロックがいくつか見
つかったのに、最終ＥＮＤマークで終わるログブロック
が存在しない場合には、それは巨大トランザクションの
途中でシステムダウンが発生したことを意味し、ログリ
プレイヤがオペレーションログのリプレイを行わなけれ
ばならないことを意味する。 （２）ログの採取 （２．１）ログバッファの管理 ログをトランザクション単位にログボリューム１２０ヘ
出力するためには、メタデータの更新情報を一度、メモ
リ内に溜める必要がある。これをログバッファと呼ぶ。
ログバッファはマウント時にまとめて用意し、ファイル
システム利用中にメモリの追加獲得は行わない。
【０１７９】トランザクション毎のログ採取とし、ま
た、トランザクション動作中に他のトランザクションが
並行動作することを狙い、ファイルシステム毎にログバ
ッファを複数持つ。その数は並行動作を許すトランザク
ション数によって決められる。
【０１８０】並行動作数を限定することはログ機能追加
による性能劣化要因の１つとなるが、 ・ログリプレイ時の処理を単純化 ・巨大なログバッファを分割して使うことによる複雑さ
の回避 などのメリットが考えられるため、この方式とする。
【０１８１】各トランザクションは開始時に割り振られ
たログバッファにログを作成し、トランザクション終了
時にまとめてログライトバッファヘコピーする。ログラ
イトバッファの内容を実際にＩ／Ｏ出力するのはログラ
イトデーモン１０５と呼ぶデーモンの働きによる。
【０１８２】巨大トランザクションには、一般トランザ
クションが用いるログバッファよりも大きいログバッフ
ァ（以降、それぞれを一般ログバッファ、巨大ログバッ
ファと呼ぶ）を１つ用意する。巨大トランザクションも
当初は一般ログバッファの１つを用いる。巨大トランザ
クションとログバッファの関係には次の二段階がある。 １）あまり多くのメタデータを更新せず、一般ログバッ
ファで十分足りると判断できた時点で、次の巨大トラン
ザクションのＢＥＧＩＮを受け付ける。 ２）更新するメタデータ数がある程度多く、一般ログバ
ッファでは足りないと判断できた時点で、巨大ログバッ
ファにこれまでの内容をコピー、そこで処理を継続す
る。 ３）更新するメタデータ数が大変多く、巨大ログバッフ
ァでは足りない場合には、サブトランザクションとして
分割する。
【０１８３】２）におけるバッファ間のコピーが負担と
なりそうであるが、巨大トランザクションがそれほど多
くないと考えると、あまり頻繁に発生するものではない
ので、この方法とする。
【０１８４】一般ログバッファは状態（利用中・未利
用）について、ビットマップで管理される。各ログバッ
ファを管理する構造をログバッファ数の配列で確保し、
それぞれが ・ログバッファのアドレス ・これまでに採取したログサイズ を持っている。
【０１８５】また、ログバッファの内容は専用のログラ
イトデーモン１０５によってログボリューム１２０ヘ反
映するが、そのログライトデーモン１０５が複数のログ
バッファの内容を一括してＩ／Ｏ発行するために、トラ
ンザクション終了時にそれぞれのログバッファの内容を
ログライトバッファ１５０と呼ぶ専用の領域にコピーす
る。
【０１８６】ログライトバッファを管理する構造とし
て、 ・追加モードにあるログライトバッファはどちらか ・それぞれのログライトバッファに溜められたログサイ
ズ がある。
【０１８７】ログライトバッファの内容をログボリュー
ム１２０ヘ書き出している間は、その後のトランザクシ
ョンが終了するためにログライトバッファにログバッフ
ァをコピーしようとしても、Ｉ／Ｏ中であるためにガー
ドしなければならない。これは性能劣化に繋がるため避
けなければならない。そのため、ログライトバッファは
２本用意する。
【０１８８】一般トランザクションはトランザクション
開始時に、空のログバッファをビットマップより見つけ
（未利用ログバッファを０で示し、ここで１とする）、
そのビット番号がトランザクション番号となる。
【０１８９】巨大トランザクションが一般ログバッファ
にて処理進行中、一般ログバッファでは入りきらないと
判断されるとこれまでの内容をこの巨大ログバッファヘ
コピーし、そこで処理を継続する。この時、これまで用
いていた一般ログバッファは空き状態として、次のトラ
ンザクションによる利用を可能にする。 （２．２）巨大トランザクションの管理 空き領域管理ツリーや獲得済領域管理ツリーを操作する
トランザクションを巨大トランザクションと定義する。
巨大トランザクションは場合によっては木構造を大きく
変更しなければならないかもしれない。この時、サブト
ランザクション化する必要が生ずる。
【０１９０】サブトランザクション化した巨大トランザ
クションが並行動作した場合、どれもが多くのメタデー
タを更新すると、メタキャッシュ１３０がいずれ全てダ
ーティとなり、新たにメタデータを読み込んで更新しよ
うにも追い出すこともできずにデッドロックに陥ること
が考えられる。
【０１９１】そのため、巨大トランザクションについて
は並行動作ができないよう、ここではシリアライズし
た。しかし、上記の通り、多くのメタデータを更新する
可能性があると考えられるトランザクションは多い。こ
れらを全てトランザクション終了までシリアライズする
と、その性能インパクトは大きい。
【０１９２】巨大トランザクションも、場合によっては
それほど多くのメタデータを更新しないこともありえ
る。一般トランザクションと同等の数しかメタデータを
更新しないのであれば、扱いを一般トランザクションと
同様にすることによって、その性能インパクトを小さく
することが可能である。
【０１９３】そこで、巨大トランザクションが一般トラ
ンザクションと変わらない程度しかメタデータを更新し
ないと分かった時点で、この巨大トランザクションの扱
いは一般トランザクションと同じにする（デグレー
ド）。
【０１９４】巨大トランザクションはその開始時には一
般ログバッファの１つを一般トランザクション開始時と
同様に与えられる。しかし、１つの巨大トランザクショ
ンが動作中は次の巨大トランザクションにログバッファ
を与えない点が一般トランザクションの場合と異なる。
【０１９５】巨大トランザクションがある程度以上のメ
タデータを更新することが分かった時点で、これまでの
一般ログバッファの内容を巨大ログバッファヘコピー
し、そこで処理を継続する。
【０１９６】しかし、それほど多くのメタデータを更新
しないと判断されれば、そのまま一般ログバッファで処
理が継続され、また、次の巨大トランザクションに対
し、処理の開始（ログバッファの使用）を許可する。
【０１９７】こうして、巨大トランザクションを途中か
ら一般トランザクションとして扱うこと（デグレード）
を実現する。 （２．２．１）デグレード契機・サブトランザクション
化契機 巨大トランザクションは複数のサブトランザクションに
分割される場合もあれば、一般トランザクションへデグ
レードする場合もある。それぞれの判定基準は以下の通
りである。 ◎デグレード判定基準 ・一般ログバッファの残りサイズで、将来全てのメタデ
ータ更新が完了できると判断できた場合。 ◎巨大トランザクション用ログバッファへの移行契機 ・一般ログバッファの残りサイズが次のステップの最大
変更量よりも少ない場合。 ◎サブトランザクション判定基準 ・巨大ログバッファの残りサイズが次ステップの最大変
更量よりも少ない場合。 （２．３）一般トランザクションのログ採取 一般トランザクションは、以下の手順に従いログを採取
する。 １）ＬＯＧ＿ＢＥＧＩＮ ａ）利用するログバッファを確定する。
【０１９８】ｂ）ログバッファの先頭にＢＥＧＩＮマー
クを作成する。 ２）各メタデータの更新 ｃ）更新されたメタデータがリリースされる（ロックが
解放される）直前に、更新されたメタデータについて、
ヘッダ（更新情報）をログバッファに作成し、更新内容
をログバッファにコピーする。
【０１９９】ｄ）更新されたメタデータをリストに繋
ぐ。 ３）ＬＯＧ＿ＥＮＤ ｅ）ＥＮＤマークをログバッファに作成する。
【０２００】ｆ）ログバッファをログライトバッファヘ
コピーする。 ｇ）ログライトデーモン１０５がログボリューム１２０
ヘ反映する。 ｈ）このトランザクションで立てられた追い出し不可フ
ラグを落とす。 （２．３．１）ＬＯＧ＿ＢＥＧＩＮ トランザクション開始を意味する。同一関数内にＬＯＧ
＿ＥＮＤの宣言が必要。並行動作可能数だけ既にトラン
ザクションが動作していたら、それらのどれか１つが終
了するまで寝て待つ。
【０２０１】ａ）現在実行中のトランザクション数がロ
グバッファの数と等しい場合、それは既に許された並行
動作数だけトランザクションが実行中であることを意味
する。そのため、他トランザクションが終了するまで寝
る。そのような状態でなければ、ログバッファの利用状
況を管理するビットマップより未利用状態のログバッフ
ァを１つ選び出し、そのビットを立てる。さらに、並行
動作数カウンタをインクリメントする。
【０２０２】ｂ）前述のＢＥＧＩＮマークをログバッフ
ァの先頭に作成する。 （２．３．２）各メタデータの更新 メタデータを参照した場合にはログ採取の必要はない。
更新した場合のみログを採らなければならない。
【０２０３】ｃ）メタキャッシュ１３０に読み込んだメ
タデータについて処理が終了し、メタキャッシュ１３０
より解放するための関数（リリース関数）を呼び出す
際、「更新した」ことを明示された場合、ログを採取す
る。
【０２０４】ｉノードについてはログ対象トランザクシ
ョン内でのロック解放時がログ採取契機である。具体的
には、上記で使用権を得たログバッファにヘッダを作成
し、メタデータの更新内容をコピーする。このとき、メ
タデータの種類によってその手法が若干異なる。
【０２０５】ｃ−１）ビットマップの場合：ヘッダには
獲得（解放）したメタデータ番号を入れ、更新内容は
「０→１」「１→０」とビット操作だけとする。 ｃ−２）メタデータ本体の場合：更新内容にはメタデー
タをそのままコピーする。
【０２０６】ｃ−３）スーパブロックの場合：巨大トラ
ンザクションがデグレードした場合のみ、一般ログ内で
のスーパブロックのログ採取がありうる。その時刻（シ
ーケンシャル番号）とデータ空きサイズを記録する。
【０２０７】コピーするとともに、ログバッファのター
ミナルで管理されるログサイズに、ここで作成したログ
のサイズを加える。 ｄ）メタキャッシュ１３０の大きさは有限であることか
ら、トランザクションが進行するためには、必要のない
メタデータをメタキャッシュ１３０から追い出し、その
場所に必要なメタデータを読み込むという処理を行う追
い出し機構がある。更新されたメタデータはログを書き
出すまでは追い出されてはならない。そのために、この
メタデータをメタライトリストと呼ぶ、メタボリューム
ヘの反映を司るメタライトデーモン１０４が参照するリ
ストへ繋ぐ。 （２．３．３）ＬＯＧ＿ＥＮＤ トランザクションの終了を示す。ここで、ＥＮＤマーク
の作成を行う。ログボリューム１２０への反映はログラ
イトデーモン１０５による作業である。
【０２０８】ｅ）ＬＯＧ＿ＢＥＧＩＮにて作成したＢＥ
ＧＩＮマークに対応するＥＮＤマークをログバッファの
末尾に作成する。 ｆ）利用したログバッファの内容を追加モードにあるロ
グライトバッファにコピーする。この時にログ番号を決
定し、ＢＥＧＩＮマーク、ＥＮＤマークに埋め込む。ロ
グバッファのターミナルに記録していたログのサイズを
ログライトバッファのサイズに加える。ログバッファの
「ターミナル」とは、そのログバッファ自身の構造に関
する情報を格納する場所を意味している。同期書き込み
要求の場合は、ログライトデーモン１０５（詳細後述）
が正常にログボリューム１２０に反映したことを待つ必
要があるが、同期書き込み要求でない場合には、ログバ
ッファを解放（ビットを落とす）して終了する。
【０２０９】ｇ）後述するログライトデーモン１０５
が、ログライトバッファの内容をログボリュームヘ反映
する。 ｈ）リリース時に立てた追い出し不可フラグを全て落と
す。ただし、フラグを落とすのはログライトデーモンに
よってなされるため、このトランザクションはそのまま
終了する。 （２．４）巨大トランザクションのログ採取 巨大トランザクションも、一般トランザクションとほぼ
同様の処理だが、最大の違いは、トランザクションの状
況によってログバッファをサイズの大きい巨大ログバッ
ファヘ移行したり、サブトランザクションとして分割し
たログ採取を行わなければならない場合があることであ
る。 １）ＬＯＧ＿ＢＥＧＩＮ ａ）利用するログバッファを確定する。
【０２１０】ｂ）ログバッファの先頭にＢＥＧＩＮマー
クを作成する。 ｃ）ＢＥＧＩＮマーク作成と同時に、オペレーションロ
グをログバッファに作成する。 ２）各メタデータの更新 メタデータがリリースされた時に「更新したこと」が明
示されたら、 ｄ）更新メタデータが空き管理情報の場合、更新メタデ
ータがリリースされる度にＢＴＦリストあるいはＢＴＡ
リストとよぶ空き管理メタデータのために用意するリス
トに繋ぐ。この時、既にリストに繋がれていればリスト
構造には手を加えない。
【０２１１】ｅ）更新メタデータが空き管理情報以外の
場合、更新されたメタデータがリリースされる度にヘッ
ダをログバッファに作成し、更新内容をログバッファ域
にコピーする。
【０２１２】ｆ）更新メタデータをリストに繋ぐ。まだ
一般ログバッファで処理している場合、 ｇ）一般ログバッファで足りるか判定する。
【０２１３】ｇ−ａ）足りないなら巨大ログバッファヘ
これまでの内容をコピー。 ｇ−ｂ）足りると確定でき、かつ、デグレード条件を満
たせば、次の巨大トランザクションを受け付ける。
【０２１４】ｇ−ｃ）まだ判断ができなければそのまま
継続する。既に巨大ログバッファで処理している場合、 ｈ）サブトランザクション化するか判定する。
【０２１５】ｈ−ａ）するなら、ＢＴＦリスト及びＢＴ
Ａリストをたどりながらそれらをログバッファにコピ
ー、ＥＮＤマークを作成し、ログライトバッファヘコピ
ーする。ログライトデーモン１０５を起動し、ログを出
力する。
【０２１６】ｈ−ｂ）まだしないなら、そのまま継続す
る。 ３）ＬＯＧ＿ＥＮＤ ｉ）最終ＥＮＤマークをログバッファに作成する。
【０２１７】ｊ）ログバッファをログライトバッファヘ
コピーする。 ｋ）ログライトデーモン１０５がログボリューム１２０
ヘ反映する。 ｌ）このトランザクションで立てられた追い出し不可フ
ラグを落とす。 （２．４．１）ＬＯＧ＿ＢＥＧＩＮ 巨大トランザクションも最初は一般ログバッファを用い
る。
【０２１８】ａ）一般トランザクションの場合は、現在
の並行動作トランザクション数とログバッファの数との
関係によってログバッファを獲得できるかどうかが定ま
った。巨大トランザクションの場合は、現在他の巨大ト
ランザクションが動作中か否かが問題であり、一般トラ
ンザクションの並行動作数とは関係しない。巨大トラン
ザクションが動作中か否かのフラグを調査し、非動作中
であれば、そのフラグを立て、ログバッファの利用状況
を管理するビットマップより未利用状態のログバッファ
を１つ選び出し、そのビットを立てる。巨大トランザク
ションが現在動作中であれば、終了まで寝て待つ。
【０２１９】ｂ）ＢＥＧＩＮマークを作成する。ここ
で、トランザクションタイプに巨大トランザクションと
なりうるトランザクションが指定されていた場合には、
必ず後ろにはオペレーションログが付随する。対応する
ＥＮＤマークがないログはリプレイしてはならない。ま
た、サブトランザクション化しているのに、最終ＥＮＤ
マークがないなら、オペレーションログのリプレイが必
要である。
【０２２０】ｃ）巨大トランザクションをサブトランザ
クションログとして分割する場合にはオペレーションロ
グを採取する必要がある。ここで、オペレーションログ
とは、各ログ採取対象関数に与えられたパラメタが、将
来リプレイすることが可能な形に変更されたものであ
る。具体的には、メモリアドレスで与えられるパラメタ
は、メタボリューム内のオフセットに変更して記録す
る。 （２．４．２）各メタデータの更新 ｄ）更新メタデータが空き管理情報である場合、一回の
トランザクションで同一の領域が何度も変更される場合
が考えられる。その都度、ログを採取しているとログバ
ッファやログボリュームがフルになる可能性が高まる。
これを回避するために、更新情報をリストによって管理
し、複数回更新された空き管理メタデータを１つにまと
めてログに記録する。具体的には、メタデータの状態毎
にリスト管理する専用のＢＴＦリスト及びＢＴＡリスト
に繋がれる。このリストに繋がれていれば、そのデータ
はダーティであることを意味する。初めて更新するデー
タであれば、ターミナルから繋がるリストに追加する。
既にリストに繋がれているのであれば、２回目以降の更
新であることを意味し、ポインタについてはそのままで
良い。リストにメタデータを追加する場合には、ログサ
イズを更新する。
【０２２１】ｅ）更新メタデータが空き管理情報以外で
あれば、同一メタデータに対して何度もホールド／リリ
ースが発行されるとは考えられないので、リリースの度
（ロック解放の度）にログバッファヘコピーする（一般
トランザクションの場合と同じ）。ログサイズを更新す
る。
【０２２２】ｆ）既に何度か述べたが、更新されたメタ
データがログよりも先にメタボリューム１１１〜１１３
ヘ反映されてはならない。この追い出し不可状態もリス
ト構造によって管理される。
【０２２３】ｇ）この巨大トランザクションが更新する
メタデータが、以降、どれだけの数のメタデータを更新
するかを算出することによって、処理が分かれる。 ｇ−ａ）現在利用している一般ログバッファの残りでは
次ステップの実行によるメタデータの更新の全てをまか
ないきれない場合があると判断した場合には、巨大ログ
バッファヘの移管を行う。
【０２２４】ｇａ−１）これまでに溜まったログバッフ
ァの内容を巨大ログバッファヘコピーする。この時、Ｂ
ＴＦリストはそのまま繋いだままとし、ＢＴＡリストは
巨大トランザクション用のターミナルヘ移動する。
【０２２５】ｇａ−２）巨大ログバッファを利用して、
その巨大トランザクションは処理を継続する。 ｇ−ｂ）現在利用している一般ログバッファの残りだけ
で、以降のメタデータ更新を全て記録できると判断でき
るならば、この巨大トランザクションは一般トランザク
ションにデグレードする。ＢＴＦリストにメタデータが
繋がれている場合はデグレード条件を満たさないため、
ここでの処理はありえない。ＢＴＦリストはそのまま利
用を続ける。
【０２２６】ｇｂ−１）巨大トランザクションが動作中
か否かを示すフラグを落とす。 ｇｂ−２）一般トランザクションの並行動作数カウンタ
をインクリメント。 ｇｂ−３）次の巨大トランザクションが寝ているならば
起こして、実行を受け付ける。
【０２２７】ｇｂ−４）このまま一般ログバッファを利
用して処理を継続する。 ｇ−ｃ）まだ判断できないのであれば、このまま一般ロ
グバッファを利用して処理を継続する。
【０２２８】ｈ）サブトランザクション判定基準（前
述）に基づき、このトランザクションをサブトランザク
ション化するかどうか判定する。 ｈ−ａ）サブトランザクションに分割する場合は、 ｈａ−１）更新された空き管理情報を、リストを辿りな
がらログバッファヘコピーする。
【０２２９】ｈａ−２）ＥＮＤマークを作成する。 ｈａ−３）ログライトバッファヘコピーする。 ｈａ−４）ログライトサイズを更新する。
【０２３０】ｈａ−５）ログライトデーモン１０５を強
制起動する。 ｈａ−６）ここで変更した全てのメタデータの追い出し
不可フラグを落としてメタライトリストに繋ぐ。これに
より，メタライトデーモン１０４は任意の時ににこれら
のメタデータを書き出すことが可能となる。
【０２３１】ｈａ−７）巨大ログバッファの先頭にＢＥ
ＧＩＮマークを作成する。 ｈａ−８）オペレーションログを作成する。 ｈ−ｂ）サブトランザクションに分割する必要がない間
は、巨大ログバッファ内でそのまま継続する。 （２．４．３）ＬＯＧ＿ＥＮＤ トランザクションの終了を示す。ここで、最終ＥＮＤマ
ークの作成を行う。実際のログボリューム１２０への反
映はログライトデーモン１０５の仕事である。
【０２３２】ｉ）最終ＥＮＤマークを作成する。最終Ｅ
ＮＤマークは通常のＥＮＤマークとマジックワードが異
なるだけである。 ｊ）利用したログバッファの内容を追加モードにあるロ
グライトバッファヘコピーする。この時にログ番号を決
定し、ログサイズをログライトサイズに加える。同期書
き込み要求の場合は、ログライトデーモン１０５が正常
にログボリューム１２０に反映したことを待つ必要があ
るが、その他の場合には待たないで次の処理へ進む（す
なわち非同期書き出しである）。巨大トランザクション
動作中フラグを落とし、寝て待つ次の巨大トランザクシ
ョンを起こす。
【０２３３】ｋ）ログライトデーモン１０５が、ログラ
イトバッファの内容をログボリュームヘ反映する。 ｌ）更新したメタデータをログバッファヘコピーした時
に立てた追い出し不可フラグを全て落とす。ただし、フ
ラグを落とすのはログライトデーモン１０５によってな
されるため、このトランザクションはそのまま終了す
る。 （２．５）ログライトデーモン 並行して動作し、順次終了するトランザクションによっ
て更新されたメタデータのログは専用の書き出しデーモ
ン（ログライトデーモン１０５）によってログボリュー
ムヘ反映する。このデーモンはマウント時に起動され、
アンマウント時に停止する。すなわち、ファイルシステ
ム毎にスレッドを生成する。
【０２３４】各トランザクションが終了すると、ログバ
ッファ内にＥＮＤマークが作成され、このログバッファ
の内容はログライトバッファ１５０にコピーされる。こ
のログライトバッファ１５０は複数のログバッファの内
容を一括してログボリューム１２０に反映するためのも
のであり、そこにはメモリコピーの負担があるが、何度
もＩ／Ｏを発行するよりは良いと考える。
【０２３５】ログライトバッファ１５０ヘコピーされる
と、そのログバッファは利用中バッファリストから空き
バッファリストヘと繋ぎ直され、かつ、トランザクショ
ンが同期書き込み要求でなければ、動作中トランザクシ
ョン数をデクリメントする。これにより、次トランザク
ションの実行が進むようになる。
【０２３６】ログライトデーモン１０５はログライトバ
ッファの内容を、定期的、あるいは同期書き込み指定の
トランザクションがある場合などにログボリュームに反
映する。反映している間（Ｉ／Ｏ中）は２本あるログラ
イトバッファのうち、もう片方のログライトバッファに
内容をコピーしてそのトランザクションは処理を終了す
る。 （２．５．１）処理手順 ログライトデーモン１０５単体の処理手順はそれほど複
雑ではない。
【０２３７】ａ）現在のログライトバッファをライトモ
ードにし、もう片方を追加モードにする。 ｂ）ログライトバッファの内容をログボリューム１２０
ヘ同期書き出しする。
【０２３８】ｏ）場合に応じて有効範囲情報を書き出
す。 ｄ）ログ待ちリストに繋がるメタデータを、メタライト
リストヘ繋ぎかえる。 ｅ）規定時間の間、スリープする。
【０２３９】ｆ）規定時問が経過、または他の要因で起
こされたらａ）へ。 以下、詳細説明である。 ａ）Ｉ／Ｏ中はその対象域に対して追加更新は許されな
い。そのため、現在のログライトバッファが書き出しが
終わり、次の書き出しが始まるまでは、もう片方のログ
ライトバッファヘ終了したログバッファをコピーするよ
う設定する。Ｉ／Ｏ中のログライトバッファをライトモ
ード、ログバッファの内容をコピーする方を追加モード
と呼ぶ。切り替えはこのデーモンによって行われ、各ト
ランザクションは常に追加モードにあるログライトバッ
ファに自ログバッファの内容をコピーする。
【０２４０】ｂ）ログライトバッファに新しい内容が含
まれていないのであれば、Ｉ／Ｏを発行する必要はな
い。そこで、まずログライトサイズを調べ、ゼロであれ
ばＩ／Ｏを発行せず、タイマを指定して再び寝る。書き
出すべきログが存在するのであれば、以下の手順に従
う。
【０２４１】ｂ−ａ）ログボリュームの空きサイズ判
定。ログボリュームの先頭オフセット（Ａ）、メタライ
トリスト先頭のメタデータを管理する構造の上書き可能
オフセット（Ｂ）を調べる。それとログライトオフセッ
ト（Ｃ）、及びログボリュームの最終オフセット（Ｄ）
から以下の手順となる。 ・Ａ＜Ｂ≦Ｃ＜Ｄ ログライトサイズが（Ｄ−Ｃ）以下ならば、Ｃから書
き出す。 ログライトサイズが（Ｄ−Ｃ）より大きく、かつ、
（Ｂ−Ａ）以下ならば、Ａから書き出す。 ・Ａ≦Ｃ＜Ｂ≦Ｄ ログライトサイズが（Ｂ−Ｃ）より小さければ、Ｃか
ら書き出す。
【０２４２】これらの条件に合致せず、ログの出力がで
きない場合には、メタライトデーモン１０４を起動し
て、自分はスリープする。メタライトデーモン１０４の
動作により起動されたら、再度、空きサイズ判定から行
う。
【０２４３】ｂ−ｂ）ログボリューム１２０ヘ同期書き
出しする。 ｂ−ｃ）エラー判定。同期書き出し後、エラー判定を行
う。エラーが発見された場合の処置については省略す
る。
【０２４４】ｂ−ｄ）領域判定。 書き出しが終わった後、再び、ｂ−ａ）と同様な空き領
域の判定を行う。ここで、残りが少ないと判定された
時、その残りの大きさに応じてメタライトデーモン１０
４を「平常起動」または「緊急起動」する。
【０２４５】ｃ）ファイルシステム復元に必要なログ
は、メタライトリスト先頭の上書き可能オフセットから
たった今書き出した位置までである。そこで、それを有
効範囲情報としてディスクヘ書き出す。ここで、書き出
しはログのシーケンシャル性を考慮し、ある程度の間隔
をおいて行う。ここでは、回数に応じて、数回に一回、
書き出すこととした。
【０２４６】ｄ）ｂ）にて書き出したログに含まれるメ
タデータは全て「ログ未反映状態」、すなわち追い出し
不可状態としてリスト（ログ未反映リスト）に繋がれて
いるはずである。そこで、ログ未反映リストを辿りなが
ら、そこに繋がるメタデータをメタライトリストに追加
することにより、メタライトデーモン１０４が任意の時
にこれらのメタデータをメタボリュームに反映できるよ
うになる。
【０２４７】ｅ）ログもシステム全体から見れば非同期
書き出しとし、トランザクションが同期書き込み要求で
なければ、ログを書き出す前にそのトランザクションは
終了することができる。さらにＩ／Ｏ発行回数を削減す
るために、複数のトランザクションを一括して書き出す
ために、しばらくの間スリープし、その間にログライト
バッファヘ複数トランザクションのログを溜める。
【０２４８】ｆ）規定時間後には自分で起きて、処理を
繰り返す。しかし、他要因によって突然起こされて処理
を始める場合もある。「その他の要因については次の項
（２．５．２）で述べる。 （２．５．２）動作契機 ログライトデーモン１０５は以下の契機でログライトバ
ッファの内容をログボリュームへ書き出す。 ◎一定周期 ログライトデーモン１０５は一定周期毎にスリープ状態
から自発的に目覚め、ログライトバッファ１５０の内容
をログボリューム１２０ヘ反映する。 ◎同期書き込み要求のトランザクション トランザクションによっては同期書き込み要求で呼ばれ
る場合がある。このトランザクションについては、ログ
の書き出しを待たなければ終了してはならない。そのた
め、ＬＯＧ＿ＥＮＤ呼び出し後に、明示的にＬＯＧ＿Ｓ
ＹＮＣを行う。ＬＯＧ＿ＳＹＮＣはログライトデーモン
１０５が寝ている場合には起こし、ログライトバッファ
の内容をその場で書き出させる。
【０２４９】現在ログライトデーモン１０５がＩ／Ｏ中
であったら、ログライトデーモン１０５の処理が終わる
のを寝て待つ。 ◎ログライトバッファ不足 周期毎にログライトバッファをクリアしても、大きなロ
グバッファが連続して終了すると、その前にログライト
バッファがフルに近い状態になることがありえる。この
時にはログライトデーモン１０５が起こされ、ログライ
トバッファ１５０の内容をログボリューム１２０に書き
出してクリアする。
【０２５０】具体的には、あるトランザクションが自ロ
グバッファの内容をＬＯＧ＿ＥＮＤによってコピーしよ
うとした時、ログライトバッファ１５０の残りサイズが
自ログよりも小さいと判断された時、ログライトデーモ
ン１０５を起こし、追加モードのログライトバッファ１
５０を切り替えてもらい、その間は寝て待つ。
【０２５１】現在Ｉ／Ｏ中であり、かつ追加モードのロ
グライトバッファ１５０が足りなくなった時には、その
トランザクションは待ち合わさざるを得ない。 ◎メタキャッシュ不足 トランザクション実行中に、メタキャッシュ１３０域の
いずれかのメタデータを追い出さなければ必要なメタデ
ータをメタボリューム１１１〜１１３から読み込むこと
ができずに処理が進まなくなる場合が考えられる。
【０２５２】そのため、トランザクションが現在キャッ
シュ上のメタデータを追い出そうとする時、メタキャッ
シュ１３０上のメタデータが全てダーティであり、か
つ、ログ待ちリストに繋がれたメタデータが存在する場
合には、ログライトデーモン１０５を起動する。 ◎アンマウント時 アンマウント時には必ず書き出さなければならない。そ
のため、アンマウント処理の延長でログライトデーモン
１０５を起こし、書き出しを行う。この時、アンマウン
トを実行するため、該当ファイルシステムにメタデータ
を更新するようなトランザクションは動作していないこ
とが保証される。従って、現在のログライトバッファの
内容を書き出せば、それで全てである。
【０２５３】ログライトとバッファの内容を書き出した
後、ログライトデーモン１０５は終了する。 （３）メタデータ管理 次に、メタデータの管理方式について説明する。メタキ
ャッシュ１３０内のメタデータはｍｅｔａｌｉｓｔ構造
体によって管理される。ｍｅｔａｌｉｓｔ構造体には以
下のメンバがある。 ・メタデータへのポインタ ・ＴＲＡＮＳ（トランザクション）リストポインタ ・メタライトリストｐｒｅｖポインタ ・メタライトリストｎｅｘｔポインタ ・ログ待ちリストｐｒｅｖポインタ ・ログ待ちリストｎｅｘｔポインタ ・ログシーケンス番号 ・ログボリューム内オフセット ・トランザクション番号 ・状態フラグ ・メタデータタイプ ・ｂｕｆ構造体実体 （３．１）メタデータの状態遷移 ｍｅｔａｌｉｓｔ構造体には次の６種類の状態があり、
４種類のリストに繋がれる。それはｍｅｔａｌｉｓｔ構
造体のフラグによって示され、それぞれ夕ーミナルを別
とするリストに繋げられることによって実現する。全て
のｍｅｔａｌｉｓｔ構造体はいずれかのリストに繋がっ
ており、例外はない。 Ａ）空き管理構造更新状態 データ空き領域を管理するメタデータがトランザクショ
ンによって更新されると、リストに繋ぎ、将来まとめて
ログバッファにコピーすることは既に述べた。トランザ
クション終了時に本リストに繋がれたメタデータが直接
ログボリュームヘ反映される。リストは並行動作数に応
じて必要である。このリストをＢＴＦリストと呼ぶ。
【０２５４】この状態にあるメタデータはまだログバッ
ファヘはコピーされておらず、同一トランザクションに
よって再度更新される場合がある。既にリストに繋がれ
ているメタデータであった場合は、リスト状態は変更し
ない。当然、メタボリュームに反映してはならない。
【０２５５】ＢＴＦリストは単方向環状リストであり、
トランザクション途中状態と同じメンバを用いて繋がれ
ている。 Ｂ）利用域管理構造更新状態 実施例ではファイルシステムをエクステント管理してい
る。ｉノードから導かれる、そのファイルが利用してい
るエクステントを示す、間接エクステントブロックにつ
いても、トランザクション内で１つの間接エクステント
ブロックが何度も更新される場合が考えられる。そこ
で、空き管理構造の場合と同様に、トランザクション中
は独自のリストに繋ぎ、トランザクション終了時にまと
めてログバッファヘコピーする。リストは並行動作数に
応じて必要である。このリストをＢＴＡリストと呼ぶ。
【０２５６】この状態にある間接エクステントブロック
はまだログバッファヘはコピーされておらず、同一トラ
ンザクションによって再度更新される場合がある。既に
リストに繋がれている間接エクステントブロックであっ
た場合は、リスト状態は変更しない。当然、メタボリュ
ームに反映してはならない。
【０２５７】ＢＴＡリストは単方向環状リストであり、
トランザクション途中状態と同じメンバを用いて繋がれ
ている。 Ｃ）トランザクション途中状態 トランザクション途中を示す。この状態のとき、該当す
るメタデータを更新したトランザクションは、ある１つ
のログバッファを専有しており、既にそこに更新後状態
がコピーされている。リストは並行動作数に応じて必要
である。このリストをＴＲＡＮＳリストと呼ぶ。
【０２５８】しかし、まだトランザクションが終了して
いないことからログがログボリューム１２０ヘ反映され
ておらず、本メタデータもメタボリュームヘの反映はで
きない。この状態にあるメタデータはファイルのロック
によって保護されているため、他トランザクションから
参照・更新されることはない。
【０２５９】ＴＲＡＮＳリストのターミナルは配列にな
っており、その要素番号はトランザクションが用いてい
るログバッファの番号（トランザクション番号）に対応
する。
【０２６０】メタライトリストやログ待ちリストに繋が
れているメタデータが繋がる場合がある。ＴＲＡＮＳリ
ストは単方向環状リストであり、ＢＴＦリストが用いる
メンバを併用する。
【０２６１】Ｄ）ログ待ち状態 トランザクションは既に終了しているが、ログライトバ
ッファの内容はログライトデーモン１０５によってログ
ボリューム１２０ヘ反映されるため、この時点ではまだ
ログボリューム１２０に反映されていない状態である。
（デーモンは同期ライトを行うが、トランザクションの
視点から見れば、ログ反映が非同期に行われているよう
に見える。） トランザクションが終了する際に、Ｃ）の状態にあるＴ
ＲＡＮＳリスト（巨大トランザクションの場合はＢＴＦ
リストも）をログ待ちリストに繋ぎかえる。このリスト
はトランザクションが終了する毎に後方へ伸びるリスト
であり、ログライトバッファと同数の２本存在する。
【０２６２】この状態にあるメタデータは既にトランザ
クションが終了しており、ログはログライトバッファに
コピーされている。トランザクションが終了しているこ
とから、他トランザクションによって参照・更新される
可能性がある。この時（他トランザクションによって状
態が変化した時）、リスト位置は変更せず、状態フラグ
だけを変更する。
【０２６３】メタライトリストに繋がれたメタデータ
が、他トランザクションによって再度更新されたため
に、トランザクション途中状態になり、そのトランザク
ションが終了したことによって、ログ待ち状態になった
場合には、このメタデータはメタライトリストにも繋が
れている。
【０２６４】ログライトデーモン１０５によって、ログ
の反映が進むと、それに応じたメタデータをメタライト
リストヘ追加していく。この時、既にメタライトリスト
に繋がれているメタデータは、そのままの位置でいなけ
ればならない。 Ｅ）書き出し可能状態 これは、ログバッファのログボリュームへ反映が終了
し、自由にメタデータをメタボリュームへ反映すること
ができるようになった状態である。この状態にあるメタ
データは他トランザクションによって参照・更新される
可能性がある。この時、リスト位置は変更せず、状態フ
ラグだけを変更する。
【０２６５】繋がるリストはメタライトリストであり、
１本だけ存在する。メタライトデーモン１０４はこのリ
ストを参照してメタボリュームヘの反映を行う。 Ｆ）Ｉ／Ｏ中状態 この状態にあるメタデータは現在非同期ライトによって
メタボリュームに対してＩ／Ｏを投げているが、まだ完
了していない。Ｉ／Ｏ途中であるため、他トランザクシ
ョンは操作することができない（参照することはでき
る）。メタライトリストにそのまま繋がれている。 （３−２）ログボリュームの上書き判定情報 ログボリュームはサイズが有限であるため、サイクリッ
クに利用し、過去のログを上書きしてシステムは動作す
る。ここで、過去のログを上書きするためには、そのト
ランザクションが更新したメタデータが全てメタボリュ
ームに反映されていることが必要である。上書き可能領
域を管理するために、以下の構造を設け、メタライトデ
ーモン１０４が変更、ログライトデーモン１０５が参照
する。 ◎ログシーケンス番号 各トランザクションが終了し、ログバッファの内容をロ
グライトバッファヘコピーする毎に与えられる、シーケ
ンシャル番号である。ログボリューム内のＢＥＧＩＮマ
ーク、ＥＮＤマークに含まれる番号と同一である。既に
ライトリストに繋がるメタデータが再度更新される場合
にも、この番号は変更されない。 ◎ロクボリューム内オフセット ログボリューム内にはトランザクション毎のログが連続
して並んでおり、上書きするためには、それぞれのトラ
ンザクションが更新した全てのメタデータがメタボリュ
ームへ反映されている必要がある。
【０２６６】同一のログ番号を持つｍｅｔａｌｉｓｔ構
造体は、ここにはそのログの先頭オフセットを挿入す
る。ＬＯＧ＿ＥＮＤによってログバッファの内容がログ
ライトバッファにコピーされる際、そのアドレスとログ
ボリュームの書き出しオフセットから導かれる。トラン
ザクション毎のログボリューム内オフセットがＴＲＡＮ
Ｓリストを辿りながら、トランザクション毎のログボリ
ューム内オフセットをそれぞれのｍｅｔａｌｉｓｔ構造
体に設定する。
【０２６７】ログライトデーモン１０５は、ログを書き
出す際にメタライトリストの先頭に繋がるｍｅｔａｌｉ
ｓｔ構造体を参照し、現在のポインタにログライトバッ
ファに入っているログサイズを足した位置が、このオフ
セット値を超えないことを確認した後で書き出しを行
う。 （３．３）メタボリュームヘの反映 トランザクションによって更新されたメタデータは、ト
ランザクションが終了しログがログボリューム１２０に
反映されるまでは書き出されてはならない。そのため
に、メタキャッシュ１３０上の各メタデータはそれぞれ
の状態に応じてリストに繋がれ、唯一メタボリュームヘ
の反映が許可されているリストはメタライトリストであ
る。
【０２６８】時間のかかるＩ／Ｏ要求をトランザクショ
ン内で行うことを避けるために、メタデータのメタボリ
ュームヘの反映はトランザクションとは関係ないところ
で動作するデーモンに委ねる。このデーモンはメタライ
トリストだけを意識し、ｍｅｔａｌｉｓｔ構造体内の情
報から状態に応じてＩ／Ｏ発行するかどうかを決定し、
関連付けられたｂｕｆ構造体を用いてメタデータをメタ
ボリュームヘ反映する。
【０２６９】デーモンはメタライトリストに繋がれたメ
タデータを書き出した後、そのメタデータをリストから
外し、ｃｌｅａｎであると設定する。 （３．４）メタライトデーモン メタライトデーモン１０４は、マウント時に起動され、
アンマウント時に停止する。すなわち、ファイルシステ
ム毎にスレッドを起動する。
【０２７０】ログ書き出しの終わったトランザクション
が更新したメタデータは、それを管理するｍｅｔａｌｉ
ｓｔ構造体が全てメタライトリストに繋がれている。メ
タライトデーモン１０４はメタライトリストに繋がるメ
タデータを、ログボリュームの残りが少なくなったと判
断された場合などに非同期でメタボリュームに反映す
る。反映している間は該当するメタデータは更新するこ
とができず、Ｉ／Ｏ終了を待ち合わせることになる。
【０２７１】メタライトデーモン１０４はメタライトリ
ストを意識し、繋がるメタデータをメタボリュームへ反
映する。これにより、ログボリュームの上書き可能領域
が拡大する。
【０２７２】しかし、メタライトリストに繋がれている
メタデータの中にも、再度トランザクションによって更
新が進み、メタボリュームヘの反映が禁じられているも
のが存在する場合がある。この時、他のメタデータを書
き出すとしても、そのメタデータについては非同期ライ
トの発行を待ちあわせなければならない。このようなメ
タデータが存在すると、以降のメタデータを全て書き出
せたとしても、上書き可能領域を拡大することができな
い。
【０２７３】メタライトデーモン１０４は他者から起動
されて処理を開始する場合と、自発的に起動する場合が
ある。以下に処理手順を述べるが、システムの状態（ロ
グボリュームの空きやメタキャッシュ１３０の空きな
ど）に応じて動作が若干異なる。また、ここで述べる処
理手順にはデーモン内だけではなく、ドライバから呼ば
れる関数での処理も含まれている。 （３．４．１）自発起動処理 メタライトデーモン１０４はタイマによって自発的に起
動して、それまでにメタライトシストに繋がれた書き出
し可能なメタデータをメタボリュームに反映する。この
時、メタライトリストの全てを書き出す訳ではなく、あ
る一定の数だけ非同期書き出しを行う。普段から少しず
つメタデータの書き出しを行っておくことによって、資
源不足による起動を避け、Ｉ／Ｏ負荷分散を図る目的が
ある。
【０２７４】ａ）自発起動時には、メタライトリストに
繋がるメタデータ数を調査する。 ｂ）メタライトリストの先頭から、メタデータの状態を
調べる。 ｃ）メタデータが書き出し可能状態であれば、その状態
をＩ／Ｏ中状態に変更し、非同期ライトを発行する。
【０２７５】ｄ）ｂ＿ｉｏｄｏｎｅの関数がＩ／Ｏの成
功を確認する。 ｅ）ｂ＿ｉｏｄｏｎｅの関数をメタライトリストから外
す。 ｆ）規定数だけ繰り返す ｇ）スリープする。
【０２７６】以下、詳細説明である。 ａ）自発起動間隔として定義する間隔毎にメタライトリ
ストに繋がるメタデータ数を確認する。具体的には、メ
タライトリストのターミナルに含まれる、リンクされた
メタデータ数を調べる。このとき、それほど多くのメタ
データが繋がれていない場合には書き出しは行わない。
【０２７７】ｂ）メタライトリストには基本的にはログ
の書き出しが終わった、書き出し可能状態のメタデータ
が繋がれている。しかし、トランザクションが終了して
メタライトリストに繋がれた後で他トランザクションに
よって更新されると、そのメタデータだけは書き出し不
可の状態に戻ってしまう。そのため、メタライトデーモ
ン１０４はメタライトリストに繋がるメタデータの状態
を確認しながら書き出し処理を行わなければならない。
【０２７８】ｃ）現在ポイントするメタデータが書き出
し可能状態であれば、その状態をＩ／Ｏ状態に書き換
え、ｍｅｔａｌｉｓｔ構造体に含まれるｂｕｆ構造体を
用いてＩ／Ｏを発行する。Ｉ／Ｏ中状態のメタデータは
他トランザクションから更新されることはない。メタデ
ータのディスクライトは非同期ライトで行い、デーモン
はＩ／Ｏの結果を待たずに次の処理へ進む。
【０２７９】メタデータが書き出し不可状態であるな
ら、そのメタデータは諦め、リストの次に繋がるメタデ
ータに進み、状態を調べる。 ｄ）非同期ライトによって発行されたＩ／Ｏの結果を判
定するのは、ｂｕｆ構造体のメンバｂ＿ｉｏｄｏｎｅに
組み込まれた関数である。この関数にはｂｕｆ構造体が
引数に与えられ、それを元にエラー判定処理を呼び出
す。ここでエラーを検出した場合には、異常系処理へ進
む（省略）。成功していた場合には、該当メタデータの
ｃｌｅａｎ数をインクリメントする。
【０２８０】ｅ）ｂ＿ｉｏｄｏｎｅに組み込まれた関数
はメタライトリストの管理も行う。引数に渡されたｂｕ
ｆ構造体の上を見るとそこはｍｅｔａｌｉｓｔ構造体に
なっており、そのフラグからＩ／Ｏ中フラグを落とし、
メタライトリストから外す。また、メタデータをダーテ
ィ状態からｃｌｅａｎ状態へ変更する。これは、メタキ
ャッシュ１３０で管理されるメタデータである場合に
は、それぞれの管理構造体で管理されており、この管理
構造体はｍｅｔａｌｉｓｔ構造体からポイントされる。
【０２８１】全ての処理が終了したら、このｍｅｔａｌ
ｉｓｔ構造体をリリースする。 ｆ）メタライトリストに繋がる書き出し可能メタデータ
を、次々とリストを辿りながら定義した数だけ処理を繰
り返す。ここで、書き出しが不可とされているメタデー
タについては、この数には含めない。また、メタライト
リストが定義数よりも少ない場合には、当然そこで終了
となる。 ｇ）スリープする。再度、自発的に起動するか、あるい
は資源不足によって他から起動されるまで、スリープは
継続する。 （３．４．２）平常処理 システム状態が以下の場合には、ここで述べる処理手順
に従いメタライトデーモン１０４は動作する。 ◎ログボリュームの残りが少ない。
【０２８２】ログライトデーモン１０５が判断する。ロ
グライトバッファを書き出す際に、上書き可能域の大き
さを計算し、これが所定の閾値を下回った時にメタライ
トデーモン１０４を起動する。 ◎メタキャッシュの残りが少ない。
【０２８３】更新リリースがあった時、各メタデータの
ｃｌｅａｎ数がデクリメントされるが、その数が所定の
閾値を下回った時にメタライトデーモン１０４を起動す
る。 ａ）メタライトリストの先頭から、メタデータの状態を
調べる。
【０２８４】ｂ）メタデータが書き出し可能状態であれ
ば、その状態をＩ／Ｏ中状態に変更し、非同期ライトを
発行する。 ｃ）ｂ＿ｉｏｄｏｎｅの関数がＩ／Ｏの成功を確認す
る。
【０２８５】ｄ）ｂ＿ｉｏｄｏｎｅの関数をメタライト
リストから外す。 ｅ）メタライトリストの最後まで繰り返す。 ｆ）スリープする。
【０２８６】以下、詳細説明である。 ａ）〜ｄ）自発的に起動した場合と同じである。 ｅ）メタライトリストを辿りながら、繋がる全ての書き
出し可能メタデータについて処理を繰り返す。平常処理
時には、書き出し不可のメタデータについては飛ばして
処理を行う。そのため、ログボリューム不足時には、メ
タライトリストの先頭、すなわち、ログボリュームの上
書き可能位置を制限しているメタデータが書き出せなけ
れば資源不足は解消しないが、平常処理であるため、こ
こでは特別な対処を行わない。
【０２８７】ｆ）タイマを設定してスリープする。 （３．４．３）緊急処理 システム状態が以下の場合には、ここで述べる処理手順
に従いメタライトデーモン１０４は動作する。 ◎ログボリュームの残りが非常に少ない。 ◎メタキャッシュ１３０の残りが非常に少ない。
【０２８８】ａ）トランザクションの新規開始を制限す
る。 ｂ）メタライトリストの先頭から、メタデータの状態を
調べる。 ｃ）メタデータが書き出し可能状態であれば、その状態
をＩ／Ｏ中状態に変更し、非同期ライトを発行する。
【０２８９】ｄ）ログ未反映状態となっているメタデー
タがあれば、ログライトデーモン１０５を起動する。 ｅ）ｂ＿ｉｏｄｏｎｅの関数がＩ／Ｏの成功を確認す
る。
【０２９０】ｆ）ｂ＿ｉｏｄｏｎｅの関数をメタライト
リストから外す。 ｇ）繰り返す。 ｈ）現在の資源状態を調査し、不足があれば、それが解
消するまで繰り返す。
【０２９１】ｉ）トランザクションの受付を開始する。 ｊ）スリープする。 以下、詳細説明である。
【０２９２】ａ）緊急時には、新規のトランザクション
の開始を受け付けない。具体的には、トランザクション
に利用するログバッファを与えないことによって、その
トランザクションのＢＥＧＩＮ宣言時にてスリープさせ
る。そのために、特定のフラグを設け、ＢＥＧＩＮ宣言
時にそのフラグを参照しなければならない。
【０２９３】ｂ）〜ｇ）ここは基本的に平常処理の場合
と同じ処理である。すなわち、メタライトリストの先頭
から、追い出し不可状態のメタデータは飛ばして、書き
出し可能状態のメタデータを順に非同期ライトによって
書き出す。
【０２９４】ただし、ｄ）だけ異なる。 ｄ）ログボリュームヘの書き出しがデーモンによって行
われることから、たとえトランザクションが終了してい
てもログが未反映のためにメタボリュームへの反映を拒
否しているメタデータが存在することが考えられる。こ
の場合は、強制的にログライトデーモン１０５を起動し
て、書き出し可能状態へ移行するように操作する。既に
ログライトデーモン１０５が動作中であれば、そのまま
先へ進む。
【０２９５】ｈ）ここで、現在の資源状態を調べる。平
常処理の動作契機となる閾値以上の資源が回復していな
ければ、再度、メタライトリスト内のメタデータ書き出
しを試みる。ここで、ｄ）によってログ未反映状態のメ
タデータが、書き出し可能となったことによって進展す
ることを期待している。複数回、繰り返すことによっ
て、新規トランザクションの受付を制限していることか
ら、資源回復までメタデータの書き出しが可能であると
考える。
【０２９６】ｉ）ａ）にて制限していたトランザクショ
ンの受付を再開する。 ｊ）タイマを設定して、スリープする。 （４）獲得解放処理 メタデータの割り当て状況を管理するビットマップの状
態として、FREE-dirtyとALLOC-dirtyを区分し、FREE-di
rtyなビットマップからは獲得しないようにする。
【０２９７】具体的には以下の通りである。 ・マウント時にビットマップを読み込む際に、１つを獲
得用と定める。説明を簡単にするため、複数読み込むビ
ットマップのうち、一番若いもの（最初に読み込むも
の）を最初の獲得用ビットマップとする。 ・獲得用ビットマップの複製を作成する。 ・獲得時には複製を検索して獲得位置を決定し、本体と
複製の両方のビットを操作する。 ・解放時には本体のみのビットを操作する。 ・複製ビットマップには解放が記録されないため、獲得
処理が進むと全てのビットが立ち、そのビットマップで
は獲得できないと判断される。その場合、現在メモリ上
にあるビットマップのうち、ＣＬＥＡＮなもの、または
ALLOC-dirtyのビットマップを次の獲得用ビットマップ
と定義し、その複製を作成する。 ・メモリ上のビットマップが全てFREE-dirtyである場合
には、どれかを追い出し、新しいビットマップを獲得用
ビットマップとして読み込む。そして、その複製を作成
する。ここで、追い出し・読み込みのアルゴリズムは従
来通りで良い。
【０２９８】獲得用ビットマップとして選ばれたビット
マップは追い出しの対象とはしない。そのためメタキャ
ッシュ域不足によって他から追い出されることはない。
また、メタライトリストに繋がったことによって、メタ
ボリュームに反映された場合にも、ＣＬＥＡＮな状態に
はなるが、複製は更新せず、そのままとする。
【０２９９】本実施の形態による効果は、以下の通りで
ある。以上説明したように、本発明によれば複数の二次
記憶装置に保存されたメタデータのログにボリューム情
報を含め、また、有効なログの位置を算出・保存するこ
とでリプレイするログ量を減少せしめ、さらに、ログボ
リューム全体のゼロクリアをする必要をなくすことによ
り、ログ機構の最大の利点であるところのファイルシス
テム復元時間の短縮に及ぼす影響を小さくし、オーバオ
ールコンピュータシステム可用性の増大に寄与するとこ
ろが大きい。
【０３００】さらに、本発明によれば一回トランザクシ
ョン内で複数回更新されるメタデータのログを一度しか
採取せず、また、ログバッファの分割や、獲得・解放処
理の特殊なログ採取方式によって複数のトランザクショ
ンの独立性を考慮し、かつ、ログ機構導入による速度性
能の劣化を最小に留めることにおいて寄与するところが
大きい。
【０３０１】加えて、本発明によればトランザクション
毎に異なるログの採取量を考慮し、多くのメタデータを
更新するトランザクションについては分割し、トランザ
クションに与えられたパラメタをもログに採取し、リプ
レイ時にそのパラメタを元に、中途で終わったトランザ
クションを再度実行することによって、オペレーション
のセマンティクスを保証した復元が可能となる面におい
て寄与するところが大きい。
【０３０２】なお、上記の処理機能は、コンピュータに
よって実現することができる。その場合、説明した処理
内容は、コンピュータで読み取り可能な記録媒体に記録
されたプログラムに記述されており、このプログラムを
コンピュータで実行することにより、上記処理がコンピ
ュータで実現される。コンピュータで読み取り可能な記
録媒体としては、磁気記録装置や半導体メモリ等があ
る。市場へ流通させる場合には、ＣＤ−ＲＯＭ(Compact
Disk Read Only Memory)やフロッピーディスク等の可
搬型記録媒体にプログラムを格納して流通させたり、ネ
ットワークを介して接続されたコンピュータの記憶装置
に格納しておき、ネットワークを通じて他のコンピュー
タに転送することもできる。コンピュータで実行する際
には、コンピュータ内のハードディスク装置等にプログ
ラムを格納しておき、メインメモリにロードして実行す
る。
【０３０３】
【発明の効果】以上説明したように、第１の発明では、
メタキャッシュ内のメタデータとともにメタデータがど
のメタボリュームから取り出されたのかを示すメタデー
タ管理情報をログとして採取するようにしたため、保持
されたログがどのメタボリュームのメタデータに関する
ログであるのかを管理することができる。その結果、複
数のログボリュームにメタデータが格納されていても、
ファイルシステムの不整合を修正することが可能とな
る。
【０３０４】また、第２の発明では、ログデータの有効
範囲を管理するようにしたため、ファイルシステムを復
元する際には、ログボリューム１２内の有効なログのみ
を用いて効率よく復元処理を行うことが可能となる。
【０３０５】また、第３の発明では、ログデータに対し
て付与するシーケンス番号の最大値を、システムの使用
可能年数以上使い続けることができる値としたことで、
常に昇順の採番が可能となり、ログボリュームのゼロク
リアに伴う処理の遅延を避けることができる。
【０３０６】また、第４の発明では、メタデータが複数
回更新される場合には、最終形態のみをログとして採取
するようにしたため、ログデータが短縮されるととも
に、ログデータの短縮に伴いファイルシステム復元時間
の短縮が図れる。
【０３０７】また、第５の発明では、割り当て管理情報
の一部の複製を獲得操作用管理情報とし、メタデータの
獲得時には獲得操作用管理情報内から取得すべきメタデ
ータを特定するが、解放時には獲得操作用管理情報の情
報を更新しないようにしたため、メタデータの解放直後
に別のトランザクションにより獲得されることがなくな
る。その結果、システムダウン時に中途までしか終了し
ていなかった解放トランザクションが解放したはずであ
る領域は、解放される直前の状態のまま保全されること
が保証される。
【０３０８】また、第６の発明では、獲得、解放操作の
ログとして、その操作対象となった情報のみを記録する
ようにしたため、ログ採取量が少量ですむ。また、第７
の発明では、複数のログバッファを設け、さらにいくつ
か異なるサイズのログバッファを用意し、トランザクシ
ョン毎のログをそのトランザクションに適したサイズの
ログバッファに格納するようにしたため、複数のトラン
ザクションが並列実行される際のトランザクションの独
立性を高めることができ、また、メモリ空間を有効に活
用できる。
【０３０９】また、第８の発明では、１つのトランザク
ションのログがログバッファに収まらない場合に、中間
ログとして完結されたログをログボリュームに書き出す
ようにしたため、部分的であるログを、ファイル復元時
には１つのトランザクションのログと同値に扱うことが
可能となり、ファイルシステムの復元時に望ましい状態
に復元するのが容易となる。
【０３１０】また、第９の発明では、ログ採取に関する
システムの状態よってトランザクションの受け入れを制
限するようにしたため、複数のトランザクションが並列
実行されることによるメモリ枯渇等の障害の発生を防止
することができる。
【図面の簡単な説明】
【図１】第１の発明の原理構成図である。
【図２】第２の発明の原理構成図である。
【図３】第３の発明の原理構成図である。
【図４】第４の発明の原理構成図である。
【図５】第５の発明の原理構成図である。
【図６】第６の発明の原理構成図である。
【図７】第７の発明の原理構成図である。
【図８】第８の発明の原理構成図である。
【図９】第９の発明の原理構成図である。
【図１０】本発明を適用するデータ処理装置のハードウ
ェア構成図である。
【図１１】ファイルシステム上で動作するログ採取機能
の構成図である。
【図１２】メタデータ管理情報を示す図である。
【図１３】ログバッファの形式を示す図である。
【図１４】有効範囲を説明する図である。
【図１５】ログ採取処理のフローチャートである。
【図１６】メタボリュームの割り当て管理状況を示す図
である。
【図１７】ビットマップによるメタデータ獲得処理を示
すフローチャートである。
【図１８】解放処理のフローチャートである。
【図１９】トランザクションの処理の開始と終了の状況
を示す図である。
【図２０】ログバッファへのログの格納状況を示す図で
ある。
【図２１】ログ採取手順を示すフローチャートである。
【図２２】ファイルシステム復元処理を示すフローチャ
ートである。
【図２３】新規トランザクションの受け入れ許否判定処
理を示すフローチャートである。
【符号の説明】 １ａ〜１ｃ メタボリューム ２ ログボリューム ３ メタキャッシュ ４ メタデータ読み込み手段 ５ メタデータ管理情報 ６ トランザクション ７ ログ採取手段 ８ ログバッファ ９ ログ書き込み手段
【手続補正２】
【補正対象書類名】図面
【補正対象項目名】図１
【補正方法】変更
【補正内容】
【図１】
【手続補正３】
【補正対象書類名】図面
【補正対象項目名】図２３
【補正方法】変更
【補正内容】
【図２３】
フロントページの続き (72)発明者 鷲見 昌司 神奈川県川崎市中原区上小田中４丁目１番 １号 富士通株式会社内 (72)発明者 山口 悟 神奈川県川崎市中原区上小田中４丁目１番 １号 富士通株式会社内 (72)発明者 谷脇 貞善 神奈川県川崎市中原区上小田中４丁目１番 １号 富士通株式会社内 (72)発明者 浜中 征志郎 神奈川県川崎市中原区上小田中４丁目１番 １号 富士通株式会社内 Ｆターム(参考） 5B082 CA17 DC06 DC12 DD04 EA02 FA02 FA12 GB05 GB06

Claims (21)

    【特許請求の範囲】
  1. 【請求項１】 ログを用いてファイルシステムの不整合
    の修正を行うデータ処理装置において、 ファイルを管理するメタデータを記憶するための二次記
    憶装置である複数のメタボリュームと、 メタデータの更新結果であるログを記憶するための二次
    記憶装置であるログボリュームと、 メタデータを記憶するために主記憶装置内に設けられた
    メタキャッシュと、 メタデータの内容が変更される際に、対象となるメタデ
    ータを前記メタキャッシュへと読み込むメタデータ読み
    込み手段と、 前記メタキャッシュ内に読み込まれたメタデータの内容
    を更新するトランザクションと、 前記メタキャッシュに読み込まれたメタデータが格納さ
    れていたメタボリュームの識別情報を管理するメタデー
    タ管理手段と、 前記メタキャッシュ内で変更されたメタデータの内容を
    ログとして採取するとともに、採取したメタデータが格
    納されていたメタボリュームの識別情報を採取するログ
    採取手段と、 前記ログ採取手段が採取した情報を保持するログバッフ
    ァと、 前記ログバッファが保持する情報を、適宜前記ログボリ
    ュームに格納するログ書き込み手段と、 を有することを特徴とするデータ処理装置。
  2. 【請求項２】 ログを用いてファイルシステムの不整合
    の修正を行うデータ処理装置において、 ファイルを管理するメタデータを記憶するための二次記
    憶装置であるメタボリュームと、 メタデータの更新結果であるログを記憶するための二次
    記憶装置であるログボリュームと、 メタデータを記憶するために主記憶装置内に設けられた
    メタキャッシュと、 メタデータの内容が変更される際に、対象となるメタデ
    ータを前記メタキャッシュへと読み込むメタデータ読み
    込み手段と、 前記メタキャッシュ内に読み込まれたメタデータの内容
    を更新するトランザクションと、 前記メタキャッシュ内で変更されたメタデータの内容を
    ログとして採取するログ採取手段と、 前記ログ採取手段が採取した情報を保持するログバッフ
    ァと、 前記ログボリューム内の領域を定期的に循環するように
    して、前記ログバッファが保持する情報を前記ログボリ
    ュームに格納するログ書き込み手段と、 前記メタキャッシュ内のメタデータをメタボリューム内
    に格納するメタデータ書き込み手段と、 前記メタデータ書き込み手段による書き込み動作を監視
    しており、変更内容が前記メタボリュームに反映されて
    いないメタデータに対応する前記ログボリューム内のロ
    グを、有効なログとして指定する有効範囲監視手段と、 ファイルシステム復元要求を受け取ると、前記ログボリ
    ュームに格納されたログの中で、前記有効範囲監視手段
    により有効なログとして指定されているログのみを用い
    て、前記メタボリューム内のメタデータの不整合を修正
    するファイルシステム復元手段と、 を有することを特徴とするデータ処理装置。
  3. 【請求項３】 ログを用いてファイルシステムの不整合
    の修正を行うデータ処理装置において、 ファイルを管理するメタデータを記憶するための二次記
    憶装置であるメタボリュームと、 メタデータの更新結果であるログを記憶するための二次
    記憶装置であるログボリュームと、 メタデータを記憶するために主記憶装置内に設けられた
    メタキャッシュと、 メタデータの内容が変更される際に、対象となるメタデ
    ータを前記メタキャッシュへと読み込むメタデータ読み
    込み手段と、 前記メタキャッシュ内に読み込まれたメタデータの内容
    を更新するトランザクションと、 前記メタキャッシュ内で変更されたメタデータの内容を
    ログとして採取するログ採取手段と、 前記ログ採取手段が採取した情報を保持するログバッフ
    ァと、 前記ログバッファが保持する情報を前記ログボリューム
    に格納するログ書き込み手段と、 前記ログボリュームに格納されたログを用いて前記メタ
    ボリューム内のメタデータの不整合を修正するファイル
    システム復元手段と、 前記ファイルシステム復元手段が前記メタボリューム内
    のメタデータの不整合を修正した時に用いられたログの
    最後のシーケンス番号を記憶する初期シーケンス番号記
    憶手段と、 前記ログ書き込み手段がログの書き込みを行う際に、シ
    ーケンス番号を昇順で採番し、採番したシーケンス番号
    を書き込むべきログに付与しており、前記ファイルシス
    テム復元手段が前記メタボリューム内のメタデータの不
    整合を修正した直後には、前記初期シーケンス番号記憶
    手段に格納されたシーケンス番号を基準として採番する
    シーケンス番号採番手段と、 を有することを特徴とするデータ処理装置。
  4. 【請求項４】 ログを用いてファイルシステムの不整合
    の修正を行うデータ処理装置において、 ファイルを管理するメタデータを記憶するための二次記
    憶装置であるメタボリュームと、 メタデータを記憶するために主記憶装置内に設けられた
    メタキャッシュと、 メタデータの内容が変更される際に、対象となるメタデ
    ータを前記メタキャッシュへと読み込むメタデータ読み
    込み手段と、 前記メタキャッシュ内に読み込まれたメタデータの内容
    を更新するトランザクションと、 前記トランザクションの種別を判断し、メタデータの更
    新を複数回行う可能性のあるトランザクションの場合に
    は、前記メタキャッシュ内で変更されたメタデータの最
    終形態のみをログとして採取するログ採取手段と、 を有することを特徴とするデータ処理装置。
  5. 【請求項５】 ログを用いてファイルシステムの不整合
    の修正を行うデータ処理装置において、 メタデータに対する割り当てを管理するための割り当て
    管理情報を複数の領域に分割して保持する割り当て管理
    情報保持手段と、 前記割り当て管理情報保持手段内の割り当て管理情報の
    一部領域の複製を生成し、獲得操作用管理情報とすると
    ともに、前記獲得操作用管理情報内に未獲得のメタデー
    タがなくなると、割り当て管理情報の別の領域の複製を
    前記獲得操作用管理情報とする獲得操作用管理情報生成
    手段と、 メタデータの獲得及び解放要求を出力するトランザクシ
    ョンと、 前記トランザクションによりメタデータの獲得要求が出
    された場合には、前記獲得操作用管理情報の中の未獲得
    のメタデータを獲得し、獲得したメタデータを獲得済み
    とするように前記獲得操作用管理情報と前記割り当て管
    理情報との内容を変更するメタデータ獲得手段と、 前記トランザクションによりメタデータの解放要求が出
    された場合には、指定されたメタデータが未獲得の状態
    となるように、前記割り当て管理情報の内容を変更する
    メタデータ解放手段と、 を有することを特徴とするデータ処理装置。
  6. 【請求項６】 ログを用いてファイルシステムの不整合
    の修正を行うデータ処理装置において、 メタデータに対する割り当てを管理するための割り当て
    管理情報を保持する割り当て管理情報保持手段と、 メタデータの獲得及び解放要求を出力するトランザクシ
    ョンと、 前記トランザクションによりメタデータの獲得要求が出
    された場合には、前記割り当て管理情報の中の未獲得の
    メタデータを獲得し、獲得したメタデータを獲得済みと
    するように前記割り当て管理情報の内容を変更するメタ
    データ獲得手段と、 前記トランザクションによりメタデータの解放要求が出
    された場合には、指定されたメタデータ未獲得の状態と
    なるように、前記割り当て管理情報の内容を変更するメ
    タデータ解放手段と、 前記割り当て管理情報内の前記メタデータ獲得手段及び
    前記メタデータ解放手段によって変更された部分の情報
    をログとして採取するログ採取手段と、 を有することを特徴とするデータ処理装置。
  7. 【請求項７】 ログを用いてファイルシステムの不整合
    の修正を行うデータ処理装置において、 ファイルを管理するメタデータを記憶するための二次記
    憶装置であるメタボリュームと、 メタデータを記憶するために主記憶装置内に設けられた
    メタキャッシュと、 メタデータの内容が変更される際に、対象となるメタデ
    ータを前記メタキャッシュへと読み込むメタデータ読み
    込み手段と、 前記メタキャッシュ内に読み込まれたメタデータの内容
    を更新する複数のトランザクションと、 ログをトランザクション毎に保持する、サイズの異なる
    複数のログバッファと、 前記メタキャッシュ内で変更されたメタデータの内容を
    ログとして採取し、前記トランザクション毎に分けて前
    記ログバッファに格納するログ採取手段と、 を有することを特徴とするデータ処理装置。
  8. 【請求項８】 前記ログ採取手段は、最初にログを格納
    する場合には、トランザクションの内容によって予想さ
    れる処理に適した大きさの前記ログバッファに格納し、
    格納対象となる前記ログバッファの記憶容量が不足して
    きたら、より大きな記憶容量のログバッファへログを移
    し替え、以後、より大きな記憶容量のログバッファをロ
    グの格納対象とすることを特徴とする請求項７記載のデ
    ータ処理装置。
  9. 【請求項９】 ログを用いてファイルシステムの不整合
    の修正を行うデータ処理装置において、 ファイルを管理するメタデータを記憶するための二次記
    憶装置であるメタボリュームと、 メタデータの更新結果であるログを記憶するための二次
    記憶装置であるログボリュームと、 メタデータを記憶するために主記憶装置内に設けられた
    メタキャッシュと、 メタデータの内容が変更される際に、対象となるメタデ
    ータを前記メタキャッシュへと読み込むメタデータ読み
    込み手段と、 前記メタキャッシュ内に読み込まれたメタデータの内容
    を更新するトランザクションと、 ログをトランザクション毎に保持するログバッファと、 前記メタキャッシュ内で変更されたメタデータの内容を
    ログとして採取し、前記ログバッファに格納するログ採
    取手段と、 前記トランザクションが終了した場合に前記ログバッフ
    ァの内容を前記ログボリュームに書き込むとともに、前
    記トランザクションによるログが前記ログバッファ内に
    格納しきれない場合には、前記ログバッファ内のデータ
    を完結したログに加工し、中間ログとして前記ログボリ
    ューム内に格納するログ書き込み手段と、 を有することを特徴とするデータ処理装置。
  10. 【請求項１０】 前記ログ書き込み手段は、前記中間ロ
    グに対して、トランザクションを実行するのに必要とさ
    れたパラメタに関する情報を付加し、 ファイルシステム復元要求を受け取ると、前記ログボリ
    ュームに格納されたログを用いて、前記メタボリューム
    内のメタデータの不整合を修正するとともに、前記中間
    ログを発見すると、前記中間ログに含まれたパラメタを
    用いて、前記トランザクションを再実行させるファイル
    システム復元手段をさらに有することを特徴とする請求
    項９記載のデータ処理装置。
  11. 【請求項１１】 ログを用いてファイルシステムの不整
    合の修正を行うデータ処理装置において、 ファイルを管理するメタデータを記憶するための二次記
    憶装置であるメタボリュームと、 メタデータの更新結果であるログを記憶するための二次
    記憶装置であるログボリュームと、 メタデータを記憶するために主記憶装置内に設けられた
    メタキャッシュと、 メタデータの内容が変更される際に、対象となるメタデ
    ータを前記メタキャッシュへと読み込むメタデータ読み
    込み手段と、 前記メタキャッシュ内に読み込まれたメタデータの内容
    を更新する、複数同時実行可能なトランザクションと、 前記トランザクションからの開始要求を受け付けると、
    ログ採取に関するシステムの動作状況を判断し、前記ト
    ランザクションの受け入れ許否を判断するトランザクシ
    ョン受け入れ判断手段と、 前記メタキャッシュ内で変更されたメタデータの内容を
    ログとして採取するログ採取手段と、 前記ログ採取手段が採取した情報を保持するログバッフ
    ァと、 前記ログバッファが保持する情報を、適宜前記ログボリ
    ュームに格納するログ書き込み手段と、 を有することを特徴とするデータ処理装置。
  12. 【請求項１２】 前記メタキャッシュ内のメタデータ
    をメタボリューム内に格納するメタデータ書き込み手段
    と、 前記メタデータ書き込み手段による書き込み動作を監視
    しており、変更内容が前記メタボリュームに反映されて
    いないメタデータに対応する前記ログボリューム内のロ
    グを、有効なログとして指定する有効範囲監視手段とを
    さらに有し、 前記トランザクション受け入れ判断手段は、前記有効範
    囲監視手段によって有効なログとされたログがログボリ
    ューム中に占める割合が一定値以上である間は、前記ト
    ランザクションの受け入れを拒絶することを特徴とする
    請求項１１記載のデータ処理装置。
  13. 【請求項１３】 ログを用いてファイルシステムの不整
    合の修正を行うファイル管理プログラムを記録したコン
    ピュータ読み取り可能な記録媒体において、ファイルを
    管理するメタデータを記憶するための二次記憶装置であ
    る複数のメタボリューム、 メタデータの更新結果であるログを記憶するための二次
    記憶装置であるログボリューム、 メタデータを記憶するために主記憶装置内に設けられた
    メタキャッシュ、 メタデータの内容が変更される際に、対象となるメタデ
    ータを前記メタキャッシュへと読み込むメタデータ読み
    込み手段、 前記メタキャッシュ内に読み込まれたメタデータの内容
    を更新するトランザクション、 前記メタキャッシュに読み込まれたメタデータが格納さ
    れていたメタボリュームの識別情報を管理するメタデー
    タ管理手段、 前記メタキャッシュ内で変更されたメタデータの内容を
    ログとして採取するとともに、採取したメタデータが格
    納されていたメタボリュームの識別情報を採取するログ
    採取手段、 前記ログ採取手段が採取した情報を保持するログバッフ
    ァ、 前記ログバッファが保持する情報を、適宜前記ログボリ
    ュームに格納するログ書き込み手段、 としてコンピュータを機能させることを特徴とするファ
    イル管理プログラムを記録したコンピュータ読み取り可
    能な記録媒体。
  14. 【請求項１４】 ログを用いてファイルシステムの不整
    合の修正を行うファイル管理プログラムを記録したコン
    ピュータ読み取り可能な記録媒体において、 ファイルを管理するメタデータを記憶するための二次記
    憶装置であるメタボリューム、 メタデータの更新結果であるログを記憶するための二次
    記憶装置であるログボリューム、 メタデータを記憶するために主記憶装置内に設けられた
    メタキャッシュ、 メタデータの内容が変更される際に、対象となるメタデ
    ータを前記メタキャッシュへと読み込むメタデータ読み
    込み手段、 前記メタキャッシュ内に読み込まれたメタデータの内容
    を更新するトランザクション、 前記メタキャッシュ内で変更されたメタデータの内容を
    ログとして採取するログ採取手段、 前記ログ採取手段が採取した情報を保持するログバッフ
    ァ、 前記ログボリューム内の領域を定期的に循環するように
    して、前記ログバッファが保持する情報を前記ログボリ
    ュームに格納するログ書き込み手段、 前記メタキャッシュ内のメタデータをメタボリューム内
    に格納するメタデータ書き込み手段、 前記メタデータ書き込み手段による書き込み動作を監視
    しており、変更内容が前記メタボリュームに反映されて
    いないメタデータに対応する前記ログボリューム内のロ
    グを、有効なログとして指定する有効範囲監視手段、 ファイルシステム復元要求を受け取ると、前記ログボリ
    ュームに格納されたログの中で、前記有効範囲監視手段
    により有効なログとして指定されているログのみを用い
    て、前記メタボリューム内のメタデータの不整合を修正
    するファイルシステム復元手段、 としてコンピュータを機能させることを特徴とするファ
    イル管理プログラムを記録したコンピュータ読み取り可
    能な記録媒体。
  15. 【請求項１５】 ログを用いてファイルシステムの不整
    合の修正を行うファイル管理プログラムを記録したコン
    ピュータ読み取り可能な記録媒体において、 ファイルを管理するメタデータを記憶するための二次記
    憶装置であるメタボリューム、 メタデータの更新結果であるログを記憶するための二次
    記憶装置であるログボリューム、 メタデータを記憶するために主記憶装置内に設けられた
    メタキャッシュ、 メタデータの内容が変更される際に、対象となるメタデ
    ータを前記メタキャッシュへと読み込むメタデータ読み
    込み手段、 前記メタキャッシュ内に読み込まれたメタデータの内容
    を更新するトランザクション、 前記メタキャッシュ内で変更されたメタデータの内容を
    ログとして採取するログ採取手段、 前記ログ採取手段が採取した情報を保持するログバッフ
    ァ、 前記ログバッファが保持する情報を前記ログボリューム
    に格納するログ書き込み手段、 前記ログボリュームに格納されたログを用いて前記メタ
    ボリューム内のメタデータの不整合を修正するファイル
    システム復元手段、 前記ファイルシステム復元手段が前記メタボリューム内
    のメタデータの不整合を修正した時に用いられたログの
    最後のシーケンス番号を記憶する初期シーケンス番号記
    憶手段、 前記ログ書き込み手段がログの書き込みを行う際に、シ
    ステムの使用可能年数以上使い続けることができる値を
    最大値としたシーケンス番号を昇順で採番し、書き込む
    べきログに付与しており、前記ファイルシステム復元手
    段が前記メタボリューム内のメタデータの不整合を修正
    した直後には、前記初期シーケンス番号記憶手段に格納
    されたシーケンス番号から昇順で採番するシーケンス番
    号採番手段、 としてコンピュータを機能させることを特徴とするファ
    イル管理プログラムを記録したコンピュータ読み取り可
    能な記録媒体。
  16. 【請求項１６】 ログを用いてファイルシステムの不整
    合の修正を行うファイル管理プログラムを記録したコン
    ピュータ読み取り可能な記録媒体において、 ファイルを管理するメタデータを記憶するための二次記
    憶装置であるメタボリューム、 メタデータを記憶するために主記憶装置内に設けられた
    メタキャッシュ、 メタデータの内容が変更される際に、対象となるメタデ
    ータを前記メタキャッシュへと読み込むメタデータ読み
    込み手段、 前記メタキャッシュ内に読み込まれたメタデータの内容
    を更新するトランザクション、 前記トランザクションの種別を判断し、メタデータの更
    新を複数回行う可能性のあるトランザクションの場合に
    は、前記メタキャッシュ内で変更されたメタデータの最
    終形態のみをログとして採取するログ採取手段、 としてコンピュータを機能させることを特徴とするファ
    イル管理プログラムを記録したコンピュータ読み取り可
    能な記録媒体。
  17. 【請求項１７】 ログを用いてファイルシステムの不整
    合の修正を行うファイル管理プログラムを記録したコン
    ピュータ読み取り可能な記録媒体において、 メタデータに対する割り当てを管理するための割り当て
    管理情報を複数の領域に分割して保持する割り当て管理
    情報保持手段、 前記割り当て管理情報保持手段内の割り当て管理情報の
    一部領域の複製を生成し、獲得操作用管理情報とすると
    ともに、前記獲得操作用管理情報内に未獲得のメタデー
    タがなくなると、割り当て管理情報の別の領域の複製を
    前記獲得操作用管理情報とする獲得操作用管理情報生成
    手段、 メタデータの獲得及び解放要求を出力するトランザクシ
    ョン、 前記トランザクションによりメタデータの獲得要求が出
    された場合には、前記獲得操作用管理情報の中の未獲得
    のメタデータを獲得し、獲得したメタデータを獲得済み
    とするように前記獲得操作用管理情報と前記割り当て管
    理情報との内容を変更するメタデータ獲得手段、 前記トランザクションによりメタデータの解放要求が出
    された場合には、指定されたメタデータが未獲得の状態
    となるように、前記割り当て管理情報の内容を変更する
    メタデータ解放手段、 としてコンピュータを機能させることを特徴とするファ
    イル管理プログラムを記録したコンピュータ読み取り可
    能な記録媒体。
  18. 【請求項１８】 ログを用いてファイルシステムの不整
    合の修正を行うファイル管理プログラムを記録したコン
    ピュータ読み取り可能な記録媒体において、 メタデータに対する割り当てを管理するための割り当て
    管理情報を保持する割り当て管理情報保持手段、 メタデータの獲得及び解放要求を出力するトランザクシ
    ョン、 前記トランザクションによりメタデータの獲得要求が出
    された場合には、前記割り当て管理情報の中の未獲得の
    メタデータを獲得し、獲得したメタデータを獲得済みと
    するように前記割り当て管理情報の内容を変更するメタ
    データ獲得手段、 前記トランザクションによりメタデータの解放要求が出
    された場合には、指定されたメタデータ未獲得の状態と
    なるように、前記割り当て管理情報の内容を変更するメ
    タデータ解放手段、 前記割り当て管理情報内の前記メタデータ獲得手段及び
    前記メタデータ解放手段によって変更された部分の情報
    をログとして採取するログ採取手段、 としてコンピュータを機能させることを特徴とするファ
    イル管理プログラムを記録したコンピュータ読み取り可
    能な記録媒体。
  19. 【請求項１９】 ログを用いてファイルシステムの不整
    合の修正を行うファイル管理プログラムを記録したコン
    ピュータ読み取り可能な記録媒体において、 ファイルを管理するメタデータを記憶するための二次記
    憶装置であるメタボリューム、 メタデータを記憶するために主記憶装置内に設けられた
    メタキャッシュ、 メタデータの内容が変更される際に、対象となるメタデ
    ータを前記メタキャッシュへと読み込むメタデータ読み
    込み手段、 前記メタキャッシュ内に読み込まれたメタデータの内容
    を更新する複数のトランザクション、 ログをトランザクション毎に保持する、サイズの異なる
    複数のログバッファ、 前記メタキャッシュ内で変更されたメタデータの内容を
    ログとして採取し、前記トランザクション毎に分けて前
    記ログバッファに格納するログ採取手段、 としてコンピュータを機能させることを特徴とするファ
    イル管理プログラムを記録したコンピュータ読み取り可
    能な記録媒体。
  20. 【請求項２０】 ログを用いてファイルシステムの不整
    合の修正を行うファイル管理プログラムを記録したコン
    ピュータ読み取り可能な記録媒体において、 ファイルを管理するメタデータを記憶するための二次記
    憶装置であるメタボリューム、 メタデータの更新結果であるログを記憶するための二次
    記憶装置であるログボリューム、 メタデータを記憶するために主記憶装置内に設けられた
    メタキャッシュ、 メタデータの内容が変更される際に、対象となるメタデ
    ータを前記メタキャッシュへと読み込むメタデータ読み
    込み手段、 前記メタキャッシュ内に読み込まれたメタデータの内容
    を更新するトランザクション、 ログをトランザクション毎に保持するログバッファ、 前記メタキャッシュ内で変更されたメタデータの内容を
    ログとして採取し、前記ログバッファに格納するログ採
    取手段、 前記トランザクションが終了した場合に前記ログバッフ
    ァの内容を前記ログボリュームに書き込むとともに、前
    記トランザクションによるログが前記ログバッファ内に
    格納しきれない場合には、前記ログバッファ内のデータ
    を完結したログに加工し、中間ログとして前記ログボリ
    ューム内に格納するログ書き込み手段、 としてコンピュータを機能させることを特徴とするファ
    イル管理プログラムを記録したコンピュータ読み取り可
    能な記録媒体。
  21. 【請求項２１】 ログを用いてファイルシステムの不整
    合の修正を行うファイル管理プログラムを記録したコン
    ピュータ読み取り可能な記録媒体において、 ファイルを管理するメタデータを記憶するための二次記
    憶装置であるメタボリューム、 メタデータの更新結果であるログを記憶するための二次
    記憶装置であるログボリューム、 メタデータを記憶するために主記憶装置内に設けられた
    メタキャッシュと、 メタデータの内容が変更される際に、対象となるメタデ
    ータを前記メタキャッシュへと読み込むメタデータ読み
    込み手段、 前記メタキャッシュ内に読み込まれたメタデータの内容
    を更新する、複数同時実行可能なトランザクション、 前記トランザクションからの開始要求を受け付けると、
    ログ採取に関するシステムの動作状況を判断し、前記ト
    ランザクションの受け入れ許否を判断するトランザクシ
    ョン受け入れ判断手段、 前記メタキャッシュ内で変更されたメタデータの内容を
    ログとして採取するログ採取手段、 前記ログ採取手段が採取した情報を保持するログバッフ
    ァ、 前記ログバッファが保持する情報を、適宜前記ログボリ
    ュームに格納するログ書き込み手段、 としてコンピュータを機能させることを特徴とするファ
    イル管理プログラムを記録したコンピュータ読み取り可
    能な記録媒体。
JP08745799A 1999-03-30 1999-03-30 データ処理装置及び記録媒体 Expired - Fee Related JP3763992B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP08745799A JP3763992B2 (ja) 1999-03-30 1999-03-30 データ処理装置及び記録媒体
US09/501,568 US6732124B1 (en) 1999-03-30 2000-02-09 Data processing system with mechanism for restoring file systems based on transaction logs

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP08745799A JP3763992B2 (ja) 1999-03-30 1999-03-30 データ処理装置及び記録媒体

Publications (2)

Publication Number Publication Date
JP2000284995A true JP2000284995A (ja) 2000-10-13
JP3763992B2 JP3763992B2 (ja) 2006-04-05

Family

ID=13915409

Family Applications (1)

Application Number Title Priority Date Filing Date
JP08745799A Expired - Fee Related JP3763992B2 (ja) 1999-03-30 1999-03-30 データ処理装置及び記録媒体

Country Status (2)

Country Link
US (1) US6732124B1 (ja)
JP (1) JP3763992B2 (ja)

Cited By (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004252933A (ja) * 2002-06-03 2004-09-09 Thomson Licensing Sa メタデータ項目の伝達を制御する方法
JP2005316635A (ja) * 2004-04-28 2005-11-10 Hitachi Ltd データ処理システムおよび方法並びにその処理プログラム
KR100781515B1 (ko) * 2006-01-10 2007-12-03 삼성전자주식회사 트랜잭션 처리를 위한 로그 정보 관리 시스템 및 방법
JP2008040699A (ja) * 2006-08-04 2008-02-21 Fujitsu Ltd Ｈｓｍ制御プログラム、ｈｓｍ制御装置、ｈｓｍ制御方法
US7640388B2 (en) 2003-10-10 2009-12-29 Sony Corporation File storage apparatus for storing file data and management information
JP4699516B2 (ja) * 2006-03-28 2011-06-15 富士通株式会社 名前空間複製プログラム、名前空間複製装置、名前空間複製方法
WO2012032727A1 (en) * 2010-09-09 2012-03-15 Nec Corporation Storage system
JP2013250982A (ja) * 2012-06-01 2013-12-12 Samsung Electronics Co Ltd 記憶装置のデータ書き込み方法
CN110719233A (zh) * 2019-10-11 2020-01-21 北京百度网讯科技有限公司 用于发送信息的方法及装置
CN113448772A (zh) * 2020-11-23 2021-09-28 北京新氧科技有限公司 一种精细化数据回滚方法及装置

Families Citing this family (450)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7581077B2 (en) 1997-10-30 2009-08-25 Commvault Systems, Inc. Method and system for transferring data in a storage operation
US6418478B1 (en) * 1997-10-30 2002-07-09 Commvault Systems, Inc. Pipelined high speed data transfer mechanism
US8234477B2 (en) 1998-07-31 2012-07-31 Kom Networks, Inc. Method and system for providing restricted access to a storage medium
US9361243B2 (en) 1998-07-31 2016-06-07 Kom Networks Inc. Method and system for providing restricted access to a storage medium
US6438661B1 (en) * 1999-03-03 2002-08-20 International Business Machines Corporation Method, system, and program for managing meta data in a storage system and rebuilding lost meta data in cache
AU6016600A (en) 1999-07-14 2001-02-05 Matsushita Electric Industrial Co., Ltd. Apparatus for providing information, information receiver and storage medium
US7035880B1 (en) 1999-07-14 2006-04-25 Commvault Systems, Inc. Modular backup and retrieval system used in conjunction with a storage area network
US7395282B1 (en) 1999-07-15 2008-07-01 Commvault Systems, Inc. Hierarchical backup and retrieval system
US7389311B1 (en) 1999-07-15 2008-06-17 Commvault Systems, Inc. Modular backup and retrieval system
US7003641B2 (en) 2000-01-31 2006-02-21 Commvault Systems, Inc. Logical view with granular access to exchange data managed by a modular data and storage management system
US6658436B2 (en) * 2000-01-31 2003-12-02 Commvault Systems, Inc. Logical view and access to data managed by a modular data and storage management system
US7155481B2 (en) 2000-01-31 2006-12-26 Commvault Systems, Inc. Email attachment management in a computer system
JP3851493B2 (ja) * 2000-06-12 2006-11-29 株式会社日立製作所 データベース検索方法及びデータベース検索システム並びにデータベース検索プログラムを記録したコンピュータ読み取り可能な記録媒体
US6983464B1 (en) * 2000-07-31 2006-01-03 Microsoft Corporation Dynamic reconfiguration of multimedia stream processing modules
US7072916B1 (en) * 2000-08-18 2006-07-04 Network Appliance, Inc. Instant snapshot
US6636879B1 (en) * 2000-08-18 2003-10-21 Network Appliance, Inc. Space allocation in a write anywhere file system
WO2002031696A1 (en) * 2000-10-09 2002-04-18 Maximum Availability Limited Method and apparatus for data processing
US7058662B2 (en) * 2000-11-30 2006-06-06 Xythos Software, Inc. Maintenance of data integrity during transfer among computer networks
JP3877519B2 (ja) * 2000-12-15 2007-02-07 株式会社日立製作所 システム回復方法およびその実施計算機システム並びにその処理プログラムを記録した記録媒体
US7730213B2 (en) * 2000-12-18 2010-06-01 Oracle America, Inc. Object-based storage device with improved reliability and fast crash recovery
US7328263B1 (en) * 2001-01-30 2008-02-05 Cisco Technology, Inc. Controlling access of concurrent users of computer resources in a distributed system using an improved semaphore counting approach
WO2002071220A1 (en) * 2001-03-05 2002-09-12 Sanpro Systems Inc. A system and a method for asynchronous replication for storage area networks
US20020169940A1 (en) * 2001-04-12 2002-11-14 Kyler Daniel B. System and method for using memory mapping to scan a master file table
US20020165902A1 (en) * 2001-05-03 2002-11-07 Robb Mary Thomas Independent log manager
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
US7269608B2 (en) * 2001-05-30 2007-09-11 Sun Microsystems, Inc. Apparatus and methods for caching objects using main memory and persistent memory
US7437525B2 (en) * 2001-05-31 2008-10-14 Oracle International Corporation Guaranteed undo retention
US7617292B2 (en) * 2001-06-05 2009-11-10 Silicon Graphics International Multi-class heterogeneous clients in a clustered filesystem
US20040139125A1 (en) 2001-06-05 2004-07-15 Roger Strassburg Snapshot copy of data volume during data access
US7640582B2 (en) 2003-04-16 2009-12-29 Silicon Graphics International Clustered filesystem for mix of trusted and untrusted nodes
US8010558B2 (en) 2001-06-05 2011-08-30 Silicon Graphics International Relocation of metadata server with outstanding DMAPI requests
GB2378782B (en) * 2001-08-16 2005-04-13 Sun Microsystems Inc Message brokering
GB2378781B (en) * 2001-08-16 2005-06-01 Sun Microsystems Inc Message brokering
US20030055809A1 (en) * 2001-09-18 2003-03-20 Sun Microsystems, Inc. Methods, systems, and articles of manufacture for efficient log record access
US7415539B2 (en) * 2001-09-28 2008-08-19 Siebel Systems, Inc. Method and apparatus for detecting insufficient memory for data extraction processes
US7257649B2 (en) * 2001-09-28 2007-08-14 Siebel Systems, Inc. Method and system for transferring information during server synchronization with a computing device
US7487168B2 (en) * 2001-11-01 2009-02-03 Microsoft Corporation System and method for loading hierarchical data into relational database systems
US20030088814A1 (en) * 2001-11-07 2003-05-08 Campbell Ralph B. Method and apparatus for logging file system operations
US7149761B2 (en) * 2001-11-13 2006-12-12 Tadpole Technology Plc System and method for managing the synchronization of replicated version-managed databases
JP2005514683A (ja) * 2001-12-06 2005-05-19 ニューヨーク・ユニバーシティ 合成、認識および圧縮のための多モード・データ集団の多重線形表現のための論理装置、データ構造、システムおよび方法
US7047358B2 (en) * 2001-12-26 2006-05-16 Boon Storage Technologies, Inc. High-performance log-structured RAID
US7036043B2 (en) * 2001-12-28 2006-04-25 Storage Technology Corporation Data management with virtual recovery mapping and backward moves
US20030131253A1 (en) * 2001-12-28 2003-07-10 Martin Marcia Reid Data management appliance
JP4323745B2 (ja) * 2002-01-15 2009-09-02 三洋電機株式会社 記憶装置
CA2370601A1 (en) * 2002-02-05 2003-08-05 Ibm Canada Limited-Ibm Canada Limitee Optimizing log usage for temporary objects
US6895529B2 (en) * 2002-02-13 2005-05-17 Bull Hn Information Systems, Inc. Rebuilding “in-doubt” states reliably after multiple system failures in a data processing system performing two-phase transaction processing
JP3971941B2 (ja) 2002-03-05 2007-09-05 三洋電機株式会社 データ記憶装置
US6850957B2 (en) * 2002-03-12 2005-02-01 Hitachi, Ltd. Information system and data access method
US6993539B2 (en) 2002-03-19 2006-01-31 Network Appliance, Inc. System and method for determining changes in two snapshots and for transmitting changes to destination snapshot
US6895413B2 (en) * 2002-03-22 2005-05-17 Network Appliance, Inc. System and method for performing an on-line check of a file system
US7155464B2 (en) * 2002-03-29 2006-12-26 Panasas, Inc. Recovering and checking large file systems in an object-based data storage system
US6993634B2 (en) * 2002-04-29 2006-01-31 Intel Corporation Active tracking and retrieval of shared memory resource information
US7546365B2 (en) * 2002-04-30 2009-06-09 Canon Kabushiki Kaisha Network device management system and method of controlling same
US7546364B2 (en) * 2002-05-16 2009-06-09 Emc Corporation Replication of remote copy data for internet protocol (IP) transmission
WO2003098578A1 (en) * 2002-05-17 2003-11-27 Xanavi Informatics Corporation Map data product, map data processing program product, map data processing method, and map data processing device
US7073038B2 (en) * 2002-05-22 2006-07-04 Storage Technology Corporation Apparatus and method for implementing dynamic structure level pointers
US7249152B2 (en) * 2002-05-24 2007-07-24 Oracle International Corporation Dynamic disk space management by multiple database server instances in a cluster configuration
US7484216B2 (en) * 2002-06-18 2009-01-27 Microsoft Corporation System and method for decoupling space reservation in transactional logging systems
JP4387087B2 (ja) * 2002-07-25 2009-12-16 三洋電機株式会社 データ記憶装置
US6934822B2 (en) * 2002-08-06 2005-08-23 Emc Corporation Organization of multiple snapshot copies in a data storage system
GB2410106B (en) 2002-09-09 2006-09-13 Commvault Systems Inc Dynamic storage device pooling in a computer system
GB2409553B (en) 2002-09-16 2007-04-04 Commvault Systems Inc System and method for optimizing storage operations
EP1403764A1 (en) * 2002-09-26 2004-03-31 Sap Ag Method and computer system for dynamic data type enrichment
KR100484485B1 (ko) * 2002-10-01 2005-04-20 한국전자통신연구원 비휘발성 메모리에의 데이터 저장 방법 및 장치
US7707184B1 (en) * 2002-10-09 2010-04-27 Netapp, Inc. System and method for snapshot full backup and hard recovery of a database
US7340486B1 (en) * 2002-10-10 2008-03-04 Network Appliance, Inc. System and method for file system snapshot of a virtual logical disk
US7024583B2 (en) * 2002-10-31 2006-04-04 Hewlett-Packard Development Company, L.P. Method and apparatus for detecting file system corruption
JP4186602B2 (ja) * 2002-12-04 2008-11-26 株式会社日立製作所 ジャーナルログを利用した更新データ書込方法
US7428751B2 (en) * 2002-12-05 2008-09-23 Microsoft Corporation Secure recovery in a serverless distributed file system
JP4290975B2 (ja) * 2002-12-19 2009-07-08 株式会社日立製作所 データベース処理方法及び装置並びにその処理プログラム及びディザスタリカバリ方法及びシステム
JP4393762B2 (ja) * 2002-12-19 2010-01-06 株式会社日立製作所 データベース処理方法及び装置並びにその処理プログラム
US7660790B1 (en) * 2005-02-24 2010-02-09 Symantec Operating Corporation Method and apparatus for utilizing a file change log
US7890469B1 (en) * 2002-12-30 2011-02-15 Symantec Operating Corporation File change log
JP2004213435A (ja) * 2003-01-07 2004-07-29 Hitachi Ltd 記憶装置システム
JP3974538B2 (ja) 2003-02-20 2007-09-12 株式会社日立製作所 情報処理システム
JP2004259079A (ja) * 2003-02-27 2004-09-16 Hitachi Ltd データ処理システム
JP2004265110A (ja) * 2003-02-28 2004-09-24 Hitachi Ltd メタデータ配置方法、プログラムおよびディスク装置
US7769722B1 (en) 2006-12-08 2010-08-03 Emc Corporation Replication and restoration of multiple data storage object types in a data network
JP4165747B2 (ja) * 2003-03-20 2008-10-15 株式会社日立製作所 記憶システム、制御装置及び制御装置のプログラム
JP4301849B2 (ja) * 2003-03-31 2009-07-22 株式会社日立製作所 情報処理方法及びその実施システム並びにその処理プログラム並びにディザスタリカバリ方法およびシステム並びにその処理を実施する記憶装置およびその制御処理方法
CA2520498C (en) 2003-04-03 2012-09-25 Commvault Systems, Inc. System and method for dynamically performing storage operations in a computer network
GB0308262D0 (en) * 2003-04-10 2003-05-14 Ibm Recovery from failures within data processing systems
US7039773B2 (en) * 2003-04-29 2006-05-02 Oracle International Corporation Method and mechanism for efficient implementation of ordered records
US7089383B2 (en) * 2003-06-06 2006-08-08 Hewlett-Packard Development Company, L.P. State machine and system for data redundancy
US7653699B1 (en) * 2003-06-12 2010-01-26 Symantec Operating Corporation System and method for partitioning a file system for enhanced availability and scalability
US7454569B2 (en) 2003-06-25 2008-11-18 Commvault Systems, Inc. Hierarchical system and method for performing storage operations in a computer network
US7567991B2 (en) * 2003-06-25 2009-07-28 Emc Corporation Replication of snapshot using a file system copy differential
US7694086B1 (en) * 2003-06-30 2010-04-06 Symantec Operating Corporation Method and system for incremental backup of data volumes
US7379925B2 (en) * 2003-07-25 2008-05-27 New York University Logic arrangement, data structure, system and method for multilinear representation of multimodal data ensembles for synthesis, rotation and compression
US7406487B1 (en) * 2003-08-29 2008-07-29 Symantec Operating Corporation Method and system for performing periodic replication using a log
US7587568B2 (en) * 2003-09-05 2009-09-08 Oracel International Corporation Method and system of reclaiming storage space in data storage systems
US7266653B2 (en) * 2003-09-29 2007-09-04 International Business Machines Corporation Remote data mirroring with acknowledgment upon writing copied data to volatile cache memory
US7085902B2 (en) * 2003-09-29 2006-08-01 International Business Machines Corporation Storage system with symmetrical mirroring
US7010721B2 (en) * 2003-09-29 2006-03-07 International Business Machines Corporation File system journal management
US20050081099A1 (en) * 2003-10-09 2005-04-14 International Business Machines Corporation Method and apparatus for ensuring valid journaled file system metadata during a backup operation
US7181647B2 (en) 2003-10-15 2007-02-20 International Business Machines Corporation Error tracking method and system
US7328376B2 (en) * 2003-10-31 2008-02-05 Sun Microsystems, Inc. Error reporting to diagnostic engines based on their diagnostic capabilities
US7401093B1 (en) * 2003-11-10 2008-07-15 Network Appliance, Inc. System and method for managing file data during consistency points
US7721062B1 (en) 2003-11-10 2010-05-18 Netapp, Inc. Method for detecting leaked buffer writes across file system consistency points
US7546324B2 (en) 2003-11-13 2009-06-09 Commvault Systems, Inc. Systems and methods for performing storage operations using network attached storage
CA2548542C (en) 2003-11-13 2011-08-09 Commvault Systems, Inc. System and method for performing a snapshot and for restoring data
CA2544063C (en) 2003-11-13 2013-09-10 Commvault Systems, Inc. System and method for combining data streams in pilelined storage operations in a storage network
US7440982B2 (en) * 2003-11-13 2008-10-21 Commvault Systems, Inc. System and method for stored data archive verification
US7613748B2 (en) 2003-11-13 2009-11-03 Commvault Systems, Inc. Stored data reverification management system and method
US7228456B2 (en) * 2003-12-01 2007-06-05 Emc Corporation Data recovery for virtual ordered writes for multiple storage devices
US7730489B1 (en) * 2003-12-10 2010-06-01 Oracle America, Inc. Horizontally scalable and reliable distributed transaction management in a clustered application server environment
JP2005189995A (ja) * 2003-12-24 2005-07-14 Hitachi Ltd ファイル授受プロセス管理方法、および、ファイル授受プロセス可視化方法、ならびに、ファイル授受システムにおけるファイル授受プロセス管理装置、および、ユーザ端末
JP2007518199A (ja) * 2004-01-13 2007-07-05 ニューヨーク・ユニバーシティ 多重線形独立要素分析を使用した画像認識の方法、システム、記憶媒体、及びデータ構造
JP4477370B2 (ja) * 2004-01-30 2010-06-09 株式会社日立製作所 データ処理システム
JP4551096B2 (ja) * 2004-02-03 2010-09-22 株式会社日立製作所 ストレージサブシステム
US7130957B2 (en) * 2004-02-10 2006-10-31 Sun Microsystems, Inc. Storage system structure for storing relational cache metadata
US7130956B2 (en) * 2004-02-10 2006-10-31 Sun Microsystems, Inc. Storage system including hierarchical cache metadata
US7346620B2 (en) * 2004-02-12 2008-03-18 International Business Machines Corporation Adjusting log size in a static logical volume
WO2005086001A1 (en) * 2004-02-27 2005-09-15 Incipient, Inc. Distributed asynchronous ordered replication
JP4452533B2 (ja) * 2004-03-19 2010-04-21 株式会社日立製作所 システムおよび記憶装置システム
US7698699B2 (en) * 2004-03-22 2010-04-13 Microsoft Corporation Computing device with relatively limited storage space and operating/file system thereof
US7647358B2 (en) * 2004-03-22 2010-01-12 Microsoft Corporation Computing device with relatively limited storage space and operating/file system thereof
US8069192B2 (en) * 2004-03-22 2011-11-29 Microsoft Corporation Computing device with relatively limited storage space and operating / file system thereof
US7130971B2 (en) * 2004-03-30 2006-10-31 Hitachi, Ltd. Assuring genuineness of data stored on a storage device
US7343459B2 (en) 2004-04-30 2008-03-11 Commvault Systems, Inc. Systems and methods for detecting & mitigating storage risks
US8266406B2 (en) 2004-04-30 2012-09-11 Commvault Systems, Inc. System and method for allocation of organizational resources
US20050246362A1 (en) * 2004-05-03 2005-11-03 Borland Devin P System and method for dynamci log compression in a file system
US20050256859A1 (en) * 2004-05-13 2005-11-17 Internation Business Machines Corporation System, application and method of providing application programs continued access to frozen file systems
US8090691B2 (en) * 2004-08-13 2012-01-03 Computer Associates Think, Inc. System and method for variable block logging with log-ahead buffers
US7711721B2 (en) * 2004-09-01 2010-05-04 International Business Machines Corporation Apparatus, system, and method for suspending a request during file server serialization reinitialization
US7627578B2 (en) * 2004-09-01 2009-12-01 International Business Machines Corporation Apparatus, system, and method for file system serialization reinitialization
US7490088B2 (en) * 2004-09-01 2009-02-10 International Business Machines Corporation Apparatus, system, and method for preserving connection/position data integrity during file server serialization reinitialization
US7496642B2 (en) * 2004-09-29 2009-02-24 International Business Machines Corporation Adaptive vicinity prefetching for filesystem metadata
US8918677B1 (en) * 2004-09-30 2014-12-23 Emc Corporation Methods and apparatus for performing data validation in a network management application
CN101077008A (zh) * 2004-10-13 2007-11-21 韩国电子通信研究院 扩展多媒体文件结构以及多媒体文件生成方法和多媒体文件执行方法
US9080894B2 (en) * 2004-10-20 2015-07-14 Electro Industries/Gauge Tech Intelligent electronic device for receiving and sending data at high speeds over a network
US7304586B2 (en) 2004-10-20 2007-12-04 Electro Industries / Gauge Tech On-line web accessed energy meter
US8185555B2 (en) * 2004-10-22 2012-05-22 International Business Machines Corporation Model extension framework
US20060101091A1 (en) * 2004-10-22 2006-05-11 International Business Machines Corporation Recovering references in an extended model
US7747733B2 (en) 2004-10-25 2010-06-29 Electro Industries/Gauge Tech Power meter having multiple ethernet ports
US7403945B2 (en) * 2004-11-01 2008-07-22 Sybase, Inc. Distributed database system providing data and space management methodology
US7499954B2 (en) * 2004-11-01 2009-03-03 International Business Machines Corporation Consistent reintegration of a failed primary instance
US8566326B2 (en) * 2004-11-05 2013-10-22 Oracle International Corporation High-performance log-based processing
US7975061B1 (en) 2004-11-05 2011-07-05 Commvault Systems, Inc. System and method for performing multistream storage operations
US7536291B1 (en) * 2004-11-08 2009-05-19 Commvault Systems, Inc. System and method to support simulated storage operations
US7716260B2 (en) * 2004-12-16 2010-05-11 Oracle International Corporation Techniques for transaction semantics for a database server performing file operations
US7627574B2 (en) * 2004-12-16 2009-12-01 Oracle International Corporation Infrastructure for performing file operations by a database server
US20060136508A1 (en) * 2004-12-16 2006-06-22 Sam Idicula Techniques for providing locks for file operations in a database management system
US7548918B2 (en) 2004-12-16 2009-06-16 Oracle International Corporation Techniques for maintaining consistency for different requestors of files in a database management system
JP4681868B2 (ja) * 2004-12-16 2011-05-11 キヤノン株式会社 情報処理装置及びその制御方法、コンピュータプログラム及び記憶媒体
US7774304B2 (en) * 2005-01-31 2010-08-10 International Business Machines Corporation Method, apparatus and program storage device for managing buffers during online reorganization
US20080162591A1 (en) * 2005-03-10 2008-07-03 Hewlett-Packard Development Company, L.P. Method of Logging Transactions and a Method of Reversing a Transaction
US20060218200A1 (en) * 2005-03-24 2006-09-28 International Business Machines Corporation Application of log records by storage servers
US20060218204A1 (en) * 2005-03-25 2006-09-28 International Business Machines Corporation Log stream validation in log shipping data replication systems
US8590044B2 (en) * 2005-04-14 2013-11-19 International Business Machines Corporation Selective virus scanning system and method
US8145686B2 (en) * 2005-05-06 2012-03-27 Microsoft Corporation Maintenance of link level consistency between database and file system
US7613743B1 (en) * 2005-06-10 2009-11-03 Apple Inc. Methods and apparatuses for data protection
US20060282471A1 (en) * 2005-06-13 2006-12-14 Mark Timothy W Error checking file system metadata while the file system remains available
US8224837B2 (en) * 2005-06-29 2012-07-17 Oracle International Corporation Method and mechanism for supporting virtual content in performing file operations at a RDBMS
US7809675B2 (en) * 2005-06-29 2010-10-05 Oracle International Corporation Sharing state information among a plurality of file operation servers
US7873683B2 (en) * 2005-07-01 2011-01-18 Qnx Software Systems Gmbh & Co. Kg File system having transaction record coalescing
US7809777B2 (en) * 2005-07-01 2010-10-05 Qnx Software Systems Gmbh & Co. Kg File system having deferred verification of data integrity
US8959125B2 (en) 2005-07-01 2015-02-17 226008 Ontario Inc. File system having inverted hierarchical structure
US7970803B2 (en) 2005-07-01 2011-06-28 Qnx Software Systems Gmbh & Co. Kg Optimized startup verification of file system integrity
CA2512385C (en) * 2005-07-08 2008-11-04 Marathon Marine Manufacturing (1996) Ltd. Cargo deck for a truck box
US7653682B2 (en) * 2005-07-22 2010-01-26 Netapp, Inc. Client failure fencing mechanism for fencing network file system data in a host-cluster environment
US7865962B2 (en) * 2005-08-15 2011-01-04 Microsoft Corporation Multi-level sequence number based lazy invalidation
US7885965B2 (en) * 2005-08-17 2011-02-08 Oracle America, Inc. Application-responsive markup language parser
US7519859B2 (en) * 2005-08-30 2009-04-14 International Business Machines Corporation Fault recovery for transaction server
US7496609B2 (en) * 2005-09-01 2009-02-24 Microsoft Corporation Dirty shutdown recovery of file system filters
US7552147B2 (en) * 2005-09-02 2009-06-23 International Business Machines Corporation System and method for minimizing data outage time and data loss while handling errors detected during recovery
US9047344B2 (en) * 2005-10-17 2015-06-02 International Business Machines Corporation Guaranteeing data and metadata referential integrity in content management archival solutions
US7620661B2 (en) * 2005-10-27 2009-11-17 International Business Machines Corporation Method for improving the performance of database loggers using agent coordination
EP1949214B1 (en) * 2005-10-28 2012-12-19 Network Appliance, Inc. System and method for optimizing multi-pathing support in a distributed storage system environment
JP2007122643A (ja) * 2005-10-31 2007-05-17 Toshiba Corp データ検索システム、メタデータ同期方法およびデータ検索装置
US7467169B2 (en) * 2005-10-31 2008-12-16 Network Appliance, Inc. Circular and bi-directional mirroring of flexible volumes
US7490096B2 (en) * 2005-11-04 2009-02-10 Sun Microsystems, Inc. Automatic intent log testing
JP4945118B2 (ja) * 2005-11-14 2012-06-06 株式会社日立製作所 記憶容量を効率的に使用する計算機システム
US7801864B2 (en) * 2005-11-28 2010-09-21 Commvault Systems, Inc. Systems and methods for using metadata to enhance data identification operations
US7822749B2 (en) * 2005-11-28 2010-10-26 Commvault Systems, Inc. Systems and methods for classifying and transferring information in a storage network
US7765187B2 (en) * 2005-11-29 2010-07-27 Emc Corporation Replication of a consistency group of data storage objects from servers in a data network
US7610304B2 (en) * 2005-12-05 2009-10-27 Oracle International Corporation Techniques for performing file operations involving a link at a database management system
CA2632935C (en) 2005-12-19 2014-02-04 Commvault Systems, Inc. Systems and methods for performing data replication
US7617262B2 (en) * 2005-12-19 2009-11-10 Commvault Systems, Inc. Systems and methods for monitoring application data in a data replication system
US7543125B2 (en) * 2005-12-19 2009-06-02 Commvault Systems, Inc. System and method for performing time-flexible calendric storage operations
US8572330B2 (en) 2005-12-19 2013-10-29 Commvault Systems, Inc. Systems and methods for granular resource management in a storage network
US20110010518A1 (en) 2005-12-19 2011-01-13 Srinivas Kavuri Systems and Methods for Migrating Components in a Hierarchical Storage Network
US7636743B2 (en) * 2005-12-19 2009-12-22 Commvault Systems, Inc. Pathname translation in a data replication system
US8930496B2 (en) 2005-12-19 2015-01-06 Commvault Systems, Inc. Systems and methods of unified reconstruction in storage systems
US8661216B2 (en) * 2005-12-19 2014-02-25 Commvault Systems, Inc. Systems and methods for migrating components in a hierarchical storage network
US7962709B2 (en) * 2005-12-19 2011-06-14 Commvault Systems, Inc. Network redirector systems and methods for performing data replication
US7620710B2 (en) 2005-12-19 2009-11-17 Commvault Systems, Inc. System and method for performing multi-path storage operations
US7651593B2 (en) 2005-12-19 2010-01-26 Commvault Systems, Inc. Systems and methods for performing data replication
US7617253B2 (en) * 2005-12-19 2009-11-10 Commvault Systems, Inc. Destination systems and methods for performing data replication
US7606844B2 (en) 2005-12-19 2009-10-20 Commvault Systems, Inc. System and method for performing replication copy storage operations
US20200257596A1 (en) 2005-12-19 2020-08-13 Commvault Systems, Inc. Systems and methods of unified reconstruction in storage systems
US7693864B1 (en) * 2006-01-03 2010-04-06 Netapp, Inc. System and method for quickly determining changed metadata using persistent consistency point image differencing
US7774391B1 (en) * 2006-03-30 2010-08-10 Vmware, Inc. Method of universal file access for a heterogeneous computing environment
US7734648B2 (en) * 2006-04-11 2010-06-08 Sap Ag Update manager for database system
US7395377B2 (en) * 2006-04-20 2008-07-01 International Business Machines Corporation Method and system for adaptive back-off and advance for non-volatile storage (NVS) occupancy level management
US7716420B2 (en) * 2006-04-28 2010-05-11 Network Appliance, Inc. Methods of converting traditional volumes into flexible volumes
US7636829B2 (en) * 2006-05-02 2009-12-22 Intel Corporation System and method for allocating and deallocating memory within transactional code
US7797692B1 (en) * 2006-05-12 2010-09-14 Google Inc. Estimating a dominant resource used by a computer program
US7478210B2 (en) * 2006-06-09 2009-01-13 Intel Corporation Memory reclamation with optimistic concurrency
US7797329B2 (en) * 2006-06-09 2010-09-14 Oracle America Inc. Method and system for enabling a synchronization-free and parallel commit phase
US7647360B2 (en) * 2006-06-19 2010-01-12 Hitachi, Ltd. System and method for managing a consistency among volumes in a continuous data protection environment
US7624129B2 (en) * 2006-06-30 2009-11-24 Microsoft Corporation Dual logging of changes to a user preference in a computer device
US7865471B1 (en) * 2006-06-30 2011-01-04 Symantec Operating Corporation Apparatus and method for accelerating database recovery
US8726242B2 (en) * 2006-07-27 2014-05-13 Commvault Systems, Inc. Systems and methods for continuous data replication
US8015215B2 (en) * 2006-08-24 2011-09-06 Oracle America, Inc. Delegation in a file system with distributed components
US7908276B2 (en) 2006-08-25 2011-03-15 Qnx Software Systems Gmbh & Co. Kg Filesystem having a filename cache
US20080059510A1 (en) * 2006-08-31 2008-03-06 Daniel Cardamore Multimedia system framework having layer consolidating access to multiple media devices
US8566503B2 (en) * 2006-08-25 2013-10-22 Qnx Software Systems Limited Multimedia filesystem having unified representation of content on diverse multimedia devices
US7613946B2 (en) * 2006-09-14 2009-11-03 International Business Machines Corporation Apparatus, system, and method for recovering a multivolume data set
US7882077B2 (en) 2006-10-17 2011-02-01 Commvault Systems, Inc. Method and system for offline indexing of content and classifying stored data
US7765361B2 (en) * 2006-11-21 2010-07-27 Microsoft Corporation Enforced transaction system recoverability on media without write-through
US8370442B2 (en) 2008-08-29 2013-02-05 Commvault Systems, Inc. Method and system for leveraging identified changes to a mail server
US8706833B1 (en) 2006-12-08 2014-04-22 Emc Corporation Data storage server having common replication architecture for multiple storage object types
US7752180B1 (en) * 2006-12-12 2010-07-06 Network Appliance, Inc. File system group consistency point
US20080147747A1 (en) * 2006-12-14 2008-06-19 Dan Cardamore Media system having synchronization with preemptive prioritization of synchronization order
US20080147878A1 (en) * 2006-12-15 2008-06-19 Rajiv Kottomtharayil System and methods for granular resource management in a storage network
US8677091B2 (en) * 2006-12-18 2014-03-18 Commvault Systems, Inc. Writing data and storage system specific metadata to network attached storage device
KR101354152B1 (ko) * 2006-12-18 2014-01-27 삼성전자주식회사 비휘발성 데이터 저장장치에 구비된 가상 파일 시스템의작업 스케줄링 방법 및 장치
US7599969B2 (en) * 2006-12-20 2009-10-06 International Business Machines Corporation Method and system for scheduling workload in databases
US8312323B2 (en) 2006-12-22 2012-11-13 Commvault Systems, Inc. Systems and methods for remote monitoring in a computer network and reporting a failed migration operation without accessing the data being moved
US20080228771A1 (en) 2006-12-22 2008-09-18 Commvault Systems, Inc. Method and system for searching stored data
US8880478B2 (en) * 2006-12-28 2014-11-04 International Business Machines Corporation Scan-free archiving
US8918427B1 (en) 2006-12-29 2014-12-23 Symantec Operating Corporation Virtualization of file input/output operations
US8301673B2 (en) * 2006-12-29 2012-10-30 Netapp, Inc. System and method for performing distributed consistency verification of a clustered file system
US7818302B2 (en) * 2007-03-09 2010-10-19 Emc Corporation System and method for performing file system checks on an active file system
US8290808B2 (en) 2007-03-09 2012-10-16 Commvault Systems, Inc. System and method for automating customer-validated statement of work for a data storage environment
US7660570B2 (en) * 2007-03-12 2010-02-09 John Mezzalingua Associates, Inc. Active step attenuator
US8219821B2 (en) 2007-03-27 2012-07-10 Netapp, Inc. System and method for signature based data container recognition
US10845399B2 (en) 2007-04-03 2020-11-24 Electro Industries/Gaugetech System and method for performing data transfers in an intelligent electronic device
US8219749B2 (en) * 2007-04-27 2012-07-10 Netapp, Inc. System and method for efficient updates of sequential block storage
US7882304B2 (en) * 2007-04-27 2011-02-01 Netapp, Inc. System and method for efficient updates of sequential block storage
US7827350B1 (en) 2007-04-27 2010-11-02 Netapp, Inc. Method and system for promoting a snapshot in a distributed file system
US8819080B2 (en) * 2007-06-13 2014-08-26 The Boeing Company System and method for collection, retrieval, and distribution of data
US7913075B2 (en) * 2007-07-03 2011-03-22 Pmc-Sierra, Inc. Systems and methods for automatic provisioning of storage and operating system installation from pre-existing iSCSI target
US8468212B2 (en) * 2007-08-08 2013-06-18 Silicon Image, Inc. Network repository for metadata
US7805632B1 (en) * 2007-09-24 2010-09-28 Net App, Inc. Storage system and method for rapidly recovering from a system failure
US8140483B2 (en) * 2007-09-28 2012-03-20 International Business Machines Corporation Transaction log management
US7996636B1 (en) 2007-11-06 2011-08-09 Netapp, Inc. Uniquely identifying block context signatures in a storage volume hierarchy
US8086564B2 (en) * 2007-12-12 2011-12-27 Oracle International Corporation Techniques for the logical replication of high-level procedures
US7836174B2 (en) * 2008-01-30 2010-11-16 Commvault Systems, Inc. Systems and methods for grid-based data scanning
US8296301B2 (en) 2008-01-30 2012-10-23 Commvault Systems, Inc. Systems and methods for probabilistic data classification
US8725986B1 (en) 2008-04-18 2014-05-13 Netapp, Inc. System and method for volume block number to disk block number mapping
US8145931B2 (en) * 2008-05-27 2012-03-27 Sharp Laboratories Of America, Inc. Imaging device with adaptive power saving behavior and method for use thereon
US20090327601A1 (en) * 2008-06-30 2009-12-31 Shachar Fienblit Asynchronous data mirroring with look-ahead synchronization record
US8190575B1 (en) * 2008-08-27 2012-05-29 Western Digital Technologies, Inc. Disk drive maintaining multiple copies of code segments
EP2164002A1 (en) * 2008-09-16 2010-03-17 Siemens Aktiengesellschaft Method for archiving data stored in a database by partition rotation
US9178842B2 (en) * 2008-11-05 2015-11-03 Commvault Systems, Inc. Systems and methods for monitoring messaging applications for compliance with a policy
US9495382B2 (en) 2008-12-10 2016-11-15 Commvault Systems, Inc. Systems and methods for performing discrete data replication
US8204859B2 (en) 2008-12-10 2012-06-19 Commvault Systems, Inc. Systems and methods for managing replicated database data
US7930588B2 (en) * 2009-01-28 2011-04-19 International Business Machines Corporation Deferred volume metadata invalidation
US8793223B1 (en) 2009-02-09 2014-07-29 Netapp, Inc. Online data consistency checking in a network storage system with optional committal of remedial changes
US8078582B2 (en) * 2009-04-06 2011-12-13 Microsoft Corporation Data change ordering in multi-log based replication
US8364644B1 (en) * 2009-04-22 2013-01-29 Network Appliance, Inc. Exclusion of data from a persistent point-in-time image
US20100318746A1 (en) * 2009-06-12 2010-12-16 Seakr Engineering, Incorporated Memory change track logging
US8392386B2 (en) 2009-08-05 2013-03-05 International Business Machines Corporation Tracking file contents
US9201684B2 (en) * 2009-08-28 2015-12-01 International Business Machines Corporation Aiding resolution of a transaction
US9110919B2 (en) * 2009-10-30 2015-08-18 Symantec Corporation Method for quickly identifying data residing on a volume in a multivolume file system
WO2011082113A1 (en) 2009-12-31 2011-07-07 Commvault Systems, Inc. Asynchronous methods of data classification using change journals and other data structures
US8402205B2 (en) * 2010-03-18 2013-03-19 Seagate Technology Llc Multi-tiered metadata scheme for a data storage array
US8504517B2 (en) 2010-03-29 2013-08-06 Commvault Systems, Inc. Systems and methods for selective data replication
US8725698B2 (en) 2010-03-30 2014-05-13 Commvault Systems, Inc. Stub file prioritization in a data replication system
US8352422B2 (en) 2010-03-30 2013-01-08 Commvault Systems, Inc. Data restore systems and methods in a replication environment
US8504515B2 (en) 2010-03-30 2013-08-06 Commvault Systems, Inc. Stubbing systems and methods in a data replication environment
US8671074B2 (en) 2010-04-12 2014-03-11 Microsoft Corporation Logical replication in clustered database system with adaptive cloning
US8315991B2 (en) * 2010-04-20 2012-11-20 International Business Machines Corporation Detecting inadvertent or malicious data corruption in storage subsystems and recovering data
US9268832B1 (en) * 2010-05-18 2016-02-23 Netapp, Inc. Sorting a data set by using a limited amount of memory in a processing system
US8572038B2 (en) 2010-05-28 2013-10-29 Commvault Systems, Inc. Systems and methods for performing data replication
US11449394B2 (en) 2010-06-04 2022-09-20 Commvault Systems, Inc. Failover systems and methods for performing backup operations, including heterogeneous indexing and load balancing of backup and indexing resources
US8504526B2 (en) 2010-06-04 2013-08-06 Commvault Systems, Inc. Failover systems and methods for performing backup operations
US8352786B2 (en) * 2010-07-20 2013-01-08 International Business Machines Corporation Compressed replay buffer
US8954664B1 (en) * 2010-10-01 2015-02-10 Western Digital Technologies, Inc. Writing metadata files on a disk
US8756361B1 (en) 2010-10-01 2014-06-17 Western Digital Technologies, Inc. Disk drive modifying metadata cached in a circular buffer when a write operation is aborted
US9268811B1 (en) * 2010-10-25 2016-02-23 Symantec Corporation Replay of writes in replication log
US9009430B2 (en) * 2010-12-02 2015-04-14 International Business Machines Corporation Restoration of data from a backup storage volume
US9021198B1 (en) 2011-01-20 2015-04-28 Commvault Systems, Inc. System and method for sharing SAN storage
US8719264B2 (en) 2011-03-31 2014-05-06 Commvault Systems, Inc. Creating secondary copies of data based on searches for content
US9767268B2 (en) 2011-04-20 2017-09-19 International Business Machines Corporation Optimizing a compiled access control table in a content management system
US8612390B2 (en) * 2011-05-02 2013-12-17 Microsoft Corporation Lightweight caching of transaction log for sequential access
US20170192705A1 (en) * 2011-05-09 2017-07-06 International Business Machines Corporation Data formats of self-contained audit objects
US8554726B2 (en) * 2011-06-01 2013-10-08 Clustrix, Inc. Systems and methods for reslicing data in a relational database
US9294564B2 (en) 2011-06-30 2016-03-22 Amazon Technologies, Inc. Shadowing storage gateway
US8756382B1 (en) 2011-06-30 2014-06-17 Western Digital Technologies, Inc. Method for file based shingled data storage utilizing multiple media types
US8806588B2 (en) 2011-06-30 2014-08-12 Amazon Technologies, Inc. Storage gateway activation process
US8832039B1 (en) 2011-06-30 2014-09-09 Amazon Technologies, Inc. Methods and apparatus for data restore and recovery from a remote data store
US8706834B2 (en) 2011-06-30 2014-04-22 Amazon Technologies, Inc. Methods and apparatus for remotely updating executing processes
US10754813B1 (en) * 2011-06-30 2020-08-25 Amazon Technologies, Inc. Methods and apparatus for block storage I/O operations in a storage gateway
US8793343B1 (en) 2011-08-18 2014-07-29 Amazon Technologies, Inc. Redundant storage gateways
US8789208B1 (en) 2011-10-04 2014-07-22 Amazon Technologies, Inc. Methods and apparatus for controlling snapshot exports
US9183245B2 (en) * 2011-11-07 2015-11-10 Sap Se Implicit group commit when writing database log entries
US9635132B1 (en) 2011-12-15 2017-04-25 Amazon Technologies, Inc. Service and APIs for remote volume-based block storage
US20130160022A1 (en) * 2011-12-19 2013-06-20 International Business Machines Corporation Transaction manager for negotiating large transactions
US8612706B1 (en) 2011-12-21 2013-12-17 Western Digital Technologies, Inc. Metadata recovery in a disk drive
US8688703B1 (en) * 2011-12-22 2014-04-01 Emc Corporation Metadata cache supporting multiple heterogeneous systems
US9135123B1 (en) * 2011-12-28 2015-09-15 Emc Corporation Managing global data caches for file system
US9223805B2 (en) * 2012-01-30 2015-12-29 Memsql, Inc. Durability implementation plan in an in-memory database system
CN102629250A (zh) * 2012-02-28 2012-08-08 杭州丰城信息技术有限公司 一种内存数据库重做日志文件的恢复方法
US9471578B2 (en) 2012-03-07 2016-10-18 Commvault Systems, Inc. Data storage system utilizing proxy device for storage operations
US9298715B2 (en) 2012-03-07 2016-03-29 Commvault Systems, Inc. Data storage system utilizing proxy device for storage operations
EP2783288A1 (en) * 2012-03-15 2014-10-01 Hitachi, Ltd. Storage system and data management method
US9342537B2 (en) 2012-04-23 2016-05-17 Commvault Systems, Inc. Integrated snapshot interface for a data storage system
US8892523B2 (en) 2012-06-08 2014-11-18 Commvault Systems, Inc. Auto summarization of content
US9519590B1 (en) * 2012-06-26 2016-12-13 EMC IP Holding Company LLC Managing global caches in data storage systems
US9183200B1 (en) * 2012-08-02 2015-11-10 Symantec Corporation Scale up deduplication engine via efficient partitioning
JP6056453B2 (ja) * 2012-12-20 2017-01-11 富士通株式会社 プログラム、データ管理方法および情報処理装置
US20140181396A1 (en) * 2012-12-20 2014-06-26 Amazon Technologies, Inc. Virtual tape using a logical data container
US10013166B2 (en) 2012-12-20 2018-07-03 Amazon Technologies, Inc. Virtual tape library system
US10379988B2 (en) 2012-12-21 2019-08-13 Commvault Systems, Inc. Systems and methods for performance monitoring
US9146928B1 (en) * 2012-12-31 2015-09-29 Emc Corporation Techniques for storing metadata of a filesystem in persistent memory
US9886346B2 (en) 2013-01-11 2018-02-06 Commvault Systems, Inc. Single snapshot for multiple agents
US9336226B2 (en) 2013-01-11 2016-05-10 Commvault Systems, Inc. Criteria-based data synchronization management
US20140222879A1 (en) * 2013-02-01 2014-08-07 Apple Inc. Method and system for unmounting an inaccessible network file system
US9250858B2 (en) * 2013-02-20 2016-02-02 International Business Machines Corporation Dual-buffer serialization and consumption of variable-length data records produced by multiple parallel threads
US9286336B2 (en) * 2013-03-12 2016-03-15 Sap Se Unified architecture for hybrid database storage using fragments
US10706009B2 (en) * 2013-03-14 2020-07-07 Oracle International Corporation Techniques to parallelize CPU and IO work of log writes
US9244775B2 (en) 2013-03-14 2016-01-26 International Business Machines Corporation Reducing reading of database logs by persisting long-running transaction data
US9576012B2 (en) 2013-03-14 2017-02-21 Oracle International Corporation Hierarchical tablespace space management
US9672237B2 (en) 2013-03-15 2017-06-06 Amazon Technologies, Inc. System-wide checkpoint avoidance for distributed database systems
US9501501B2 (en) 2013-03-15 2016-11-22 Amazon Technologies, Inc. Log record management
US11030055B2 (en) 2013-03-15 2021-06-08 Amazon Technologies, Inc. Fast crash recovery for distributed database systems
US10180951B2 (en) * 2013-03-15 2019-01-15 Amazon Technologies, Inc. Place snapshots
US9514007B2 (en) 2013-03-15 2016-12-06 Amazon Technologies, Inc. Database system with database engine and separate distributed storage service
US9229864B1 (en) * 2013-03-15 2016-01-05 Emc Corporation Managing metadata synchronization for reducing host system latency in a storage system
US9483213B1 (en) 2013-04-29 2016-11-01 Amazon Technologies, Inc. Virtual media changers
US10747746B2 (en) 2013-04-30 2020-08-18 Amazon Technologies, Inc. Efficient read replicas
US9483361B2 (en) 2013-05-08 2016-11-01 Commvault Systems, Inc. Information management cell with failover management capability
US9146946B2 (en) * 2013-05-09 2015-09-29 International Business Machines Corporation Comparing database performance without benchmark workloads
US9760596B2 (en) 2013-05-13 2017-09-12 Amazon Technologies, Inc. Transaction ordering
US9208032B1 (en) 2013-05-15 2015-12-08 Amazon Technologies, Inc. Managing contingency capacity of pooled resources in multiple availability zones
US10303564B1 (en) 2013-05-23 2019-05-28 Amazon Technologies, Inc. Reduced transaction I/O for log-structured storage systems
US9047189B1 (en) 2013-05-28 2015-06-02 Amazon Technologies, Inc. Self-describing data blocks of a minimum atomic write size for a data store
US9928285B1 (en) * 2013-06-25 2018-03-27 EMC IP Holding Company LLC Optimized cloning for backup to disk
WO2015050620A2 (en) * 2013-07-16 2015-04-09 Openpeak Inc. Method and system for backing up and restoring a virtual file system
US9923762B1 (en) * 2013-08-13 2018-03-20 Ca, Inc. Upgrading an engine when a scenario is running
US10402374B2 (en) * 2013-08-26 2019-09-03 Vmware, Inc. Log-structured storage device format
US10216949B1 (en) 2013-09-20 2019-02-26 Amazon Technologies, Inc. Dynamic quorum membership changes
US9460008B1 (en) 2013-09-20 2016-10-04 Amazon Technologies, Inc. Efficient garbage collection for a log-structured data store
US10223184B1 (en) 2013-09-25 2019-03-05 Amazon Technologies, Inc. Individual write quorums for a log-structured distributed storage system
US9699017B1 (en) 2013-09-25 2017-07-04 Amazon Technologies, Inc. Dynamic utilization of bandwidth for a quorum-based distributed storage system
US9767178B2 (en) 2013-10-30 2017-09-19 Oracle International Corporation Multi-instance redo apply
US9880933B1 (en) 2013-11-20 2018-01-30 Amazon Technologies, Inc. Distributed in-memory buffer cache system using buffer cache nodes
US9223843B1 (en) 2013-12-02 2015-12-29 Amazon Technologies, Inc. Optimized log storage for asynchronous log updates
CN103778030B (zh) * 2013-12-30 2017-09-22 上海晨思电子科技有限公司 日志子系统写入方法、错误追踪方法及处理器
US9836515B1 (en) * 2013-12-31 2017-12-05 Veritas Technologies Llc Systems and methods for adding active volumes to existing replication configurations
US9753812B2 (en) 2014-01-24 2017-09-05 Commvault Systems, Inc. Generating mapping information for single snapshot for multiple applications
US9639426B2 (en) 2014-01-24 2017-05-02 Commvault Systems, Inc. Single snapshot for multiple applications
US9632874B2 (en) 2014-01-24 2017-04-25 Commvault Systems, Inc. Database application backup in single snapshot for multiple applications
US9495251B2 (en) 2014-01-24 2016-11-15 Commvault Systems, Inc. Snapshot readiness checking and reporting
US9563518B2 (en) 2014-04-02 2017-02-07 Commvault Systems, Inc. Information management by a media agent in the absence of communications with a storage manager
US9396089B2 (en) * 2014-05-30 2016-07-19 Apple Inc. Activity tracing diagnostic systems and methods
WO2016014061A1 (en) * 2014-07-24 2016-01-28 Hewlett-Packard Development Company, L.P. Storing metadata
US9774672B2 (en) 2014-09-03 2017-09-26 Commvault Systems, Inc. Consolidated processing of storage-array commands by a snapshot-control media agent
US10042716B2 (en) 2014-09-03 2018-08-07 Commvault Systems, Inc. Consolidated processing of storage-array commands using a forwarder media agent in conjunction with a snapshot-control media agent
US11144397B2 (en) 2014-09-12 2021-10-12 Microsoft Technology Licensing, Llc Data recovery using bitmap data structure
US9507689B2 (en) * 2014-09-17 2016-11-29 International Business Machines Corporation Updating of troubleshooting assistants
US10922276B2 (en) * 2014-11-10 2021-02-16 Hewlett Packard Enterprise Development Lp Online file system check
US9448731B2 (en) 2014-11-14 2016-09-20 Commvault Systems, Inc. Unified snapshot storage management
US9648105B2 (en) 2014-11-14 2017-05-09 Commvault Systems, Inc. Unified snapshot storage management, using an enhanced storage manager and enhanced media agents
US9959178B2 (en) * 2014-11-25 2018-05-01 Sap Se Transactional and parallel log replay for asynchronous table replication
CN105740303B (zh) 2014-12-12 2019-09-06 国际商业机器公司 改进的对象存储的方法及装置
US9665585B2 (en) 2015-01-23 2017-05-30 International Business Machines Corporation Preserving high value entries in an event log
US9898213B2 (en) 2015-01-23 2018-02-20 Commvault Systems, Inc. Scalable auxiliary copy processing using media agent resources
US9904481B2 (en) 2015-01-23 2018-02-27 Commvault Systems, Inc. Scalable auxiliary copy processing in a storage management system using media agent resources
US9940590B2 (en) * 2015-03-18 2018-04-10 Ca, Inc. System and method to generate a transaction count using filtering
US10409770B1 (en) 2015-05-14 2019-09-10 Amazon Technologies, Inc. Automatic archiving of data store log data
US10599630B2 (en) 2015-05-29 2020-03-24 Oracle International Corporation Elimination of log file synchronization delay at transaction commit time
CN106294193B (zh) * 2015-06-03 2019-10-15 杭州海康威视系统技术有限公司 存储设备及基于该存储设备的分块存储方法
US10769125B2 (en) 2015-06-10 2020-09-08 International Business Machines Corporation Ordering records for timed meta-data generation in a blocked record environment
US9864774B2 (en) 2015-06-23 2018-01-09 International Business Machines Corporation Granular buffering of metadata changes for journaling file systems
US10275320B2 (en) 2015-06-26 2019-04-30 Commvault Systems, Inc. Incrementally accumulating in-process performance data and hierarchical reporting thereof for a data stream in a secondary copy operation
US10176036B2 (en) 2015-10-29 2019-01-08 Commvault Systems, Inc. Monitoring, diagnosing, and repairing a management database in a data storage management system
US10019193B2 (en) 2015-11-04 2018-07-10 Hewlett Packard Enterprise Development Lp Checkpointing a journal by virtualization of non-volatile random access memory
JP2017091456A (ja) * 2015-11-17 2017-05-25 富士通株式会社 制御装置、制御プログラムおよび制御方法
WO2017087015A1 (en) * 2015-11-19 2017-05-26 Hewlett Packard Enterprise Development Lp Count of metadata operations
US10976946B2 (en) * 2015-11-27 2021-04-13 Hitachi, Ltd. Method and computer system for managing blocks
US10503753B2 (en) 2016-03-10 2019-12-10 Commvault Systems, Inc. Snapshot replication operations based on incremental block change tracking
US10817512B2 (en) 2016-04-01 2020-10-27 Arista Networks, Inc. Standing queries in memory
US10642844B2 (en) 2016-04-01 2020-05-05 Arista Networks, Inc. Non-materialized tables with standing queries
US10783147B2 (en) 2016-04-01 2020-09-22 Arista Networks, Inc. Query result flow control in a network switch
US10783144B2 (en) * 2016-04-01 2020-09-22 Arista Networks, Inc. Use of null rows to indicate the end of a one-shot query in network switch
US10284673B2 (en) 2016-04-01 2019-05-07 Arista Networks, Inc. Interface for a client of a network device
US10860568B2 (en) 2016-04-01 2020-12-08 Arista Networks, Inc. External data source linking to queries in memory
US10380100B2 (en) * 2016-04-27 2019-08-13 Western Digital Technologies, Inc. Generalized verification scheme for safe metadata modification
US10380069B2 (en) 2016-05-04 2019-08-13 Western Digital Technologies, Inc. Generalized write operations verification method
US10339934B2 (en) 2016-06-27 2019-07-02 Google Llc Asynchronous processing of user requests
US10324809B2 (en) * 2016-09-12 2019-06-18 Oracle International Corporation Cache recovery for failed database instances
US10805238B1 (en) 2016-09-23 2020-10-13 Amazon Technologies, Inc. Management of alternative resources
US10666569B1 (en) 2016-09-23 2020-05-26 Amazon Technologies, Inc. Journal service with named clients
US10346366B1 (en) * 2016-09-23 2019-07-09 Amazon Technologies, Inc. Management of a data processing pipeline
US10423459B1 (en) 2016-09-23 2019-09-24 Amazon Technologies, Inc. Resource manager
US10417102B2 (en) 2016-09-30 2019-09-17 Commvault Systems, Inc. Heartbeat monitoring of virtual machines for initiating failover operations in a data storage management system, including virtual machine distribution logic
US10540516B2 (en) 2016-10-13 2020-01-21 Commvault Systems, Inc. Data protection within an unsecured storage environment
US10922189B2 (en) 2016-11-02 2021-02-16 Commvault Systems, Inc. Historical network data-based scanning thread generation
US10389810B2 (en) 2016-11-02 2019-08-20 Commvault Systems, Inc. Multi-threaded scanning of distributed file systems
KR101956236B1 (ko) * 2016-11-16 2019-03-11 주식회사 실크로드소프트 데이터베이스 관리 시스템에서의 데이터 복제 기법
US10762107B2 (en) * 2016-11-29 2020-09-01 Sap Se Synchronization mechanism for serialized data log replay in database systems
US10235310B2 (en) * 2016-11-29 2019-03-19 International Business Machines Corporation Deallocation of memory buffer in multiprocessor systems
US11010261B2 (en) 2017-03-31 2021-05-18 Commvault Systems, Inc. Dynamically allocating streams during restoration of data
JP6897248B2 (ja) * 2017-04-06 2021-06-30 富士通株式会社 更新反映プログラム、更新反映方法及び更新反映装置
US10489381B2 (en) * 2017-04-13 2019-11-26 Sap Se Adaptive metadata refreshing
US10896168B2 (en) * 2017-04-28 2021-01-19 Hewlett Packard Enterprise Development Lp Application-defined object logging through a file system journal
US10984041B2 (en) 2017-05-11 2021-04-20 Commvault Systems, Inc. Natural language processing integrated with database and data storage management
GB201709499D0 (en) * 2017-06-15 2017-08-02 Microsoft Technology Licensing Llc Memory management in non-volatile memory
US10565062B1 (en) * 2017-08-03 2020-02-18 Veritas Technologies Llc Systems and methods for managing replication of data to a remote storage device
US10349097B2 (en) * 2017-10-27 2019-07-09 Mti Film, Llc Metadata editor for multimedia delivery
US11481362B2 (en) * 2017-11-13 2022-10-25 Cisco Technology, Inc. Using persistent memory to enable restartability of bulk load transactions in cloud databases
US11914571B1 (en) 2017-11-22 2024-02-27 Amazon Technologies, Inc. Optimistic concurrency for a multi-writer database
US10831591B2 (en) 2018-01-11 2020-11-10 Commvault Systems, Inc. Remedial action based on maintaining process awareness in data storage management
GB201801679D0 (en) * 2018-02-01 2018-03-21 Microsoft Technology Licensing Llc Database transaction log writing and integrity checking
US10732885B2 (en) 2018-02-14 2020-08-04 Commvault Systems, Inc. Block-level live browsing and private writable snapshots using an ISCSI server
US10642886B2 (en) 2018-02-14 2020-05-05 Commvault Systems, Inc. Targeted search of backup data using facial recognition
US11048590B1 (en) 2018-03-15 2021-06-29 Pure Storage, Inc. Data consistency during recovery in a cloud-based storage system
US10484829B1 (en) 2018-04-27 2019-11-19 Microsoft Technology Licensing, Llc Methods and systems for generating maps corresponding to physical spaces, devices, and/or users
US11210323B2 (en) 2018-04-27 2021-12-28 Microsoft Technology Licensing, Llc Methods and systems for generating property keys corresponding to physical spaces, devices, and/or users
US10951482B2 (en) 2018-05-16 2021-03-16 Microsoft Technology Licensing, Llc Device identification on a building automation control network
US11456915B2 (en) 2018-05-21 2022-09-27 Microsoft Technology Licensing, Llc Device model templates
US11159469B2 (en) 2018-09-12 2021-10-26 Commvault Systems, Inc. Using machine learning to modify presentation of mailbox objects
US11663207B2 (en) * 2018-09-24 2023-05-30 Salesforce, Inc. Translation of tenant identifiers
US11308119B2 (en) * 2018-12-03 2022-04-19 International Business Machines Corporation Replicating large statements with low latency
US11200124B2 (en) 2018-12-06 2021-12-14 Commvault Systems, Inc. Assigning backup resources based on failover of partnered data storage servers in a data storage management system
US20200192572A1 (en) 2018-12-14 2020-06-18 Commvault Systems, Inc. Disk usage growth prediction system
US11055184B2 (en) 2018-12-19 2021-07-06 Vmware, Inc. In-place garbage collection of a sharded, replicated distributed state machine based on supersedable operations
US10877881B2 (en) * 2019-01-11 2020-12-29 Vmware, Inc. In-place garbage collection of a sharded, replicated distributed state machine based on mergeable operations
EP3715981A1 (de) * 2019-03-27 2020-09-30 Siemens Aktiengesellschaft Verfahren und steuersystem zum steuern einer ausführung von transaktionen
US11176042B2 (en) 2019-05-21 2021-11-16 Arm Limited Method and apparatus for architectural cache transaction logging
US11237960B2 (en) * 2019-05-21 2022-02-01 Arm Limited Method and apparatus for asynchronous memory write-back in a data processing system
US11042318B2 (en) 2019-07-29 2021-06-22 Commvault Systems, Inc. Block-level data replication
KR20210016191A (ko) 2019-08-01 2021-02-15 삼성전자주식회사 스토리지 장치
US11029855B1 (en) * 2019-10-01 2021-06-08 Datacore Software Corporation Containerized storage stream microservice
US11340815B2 (en) * 2019-10-25 2022-05-24 EMC IP Holding Company, LLC Storage management system and method
US11409666B2 (en) * 2019-11-22 2022-08-09 EMC IP Holding Company LLC Techniques for providing I/O hints using I/O flags
US11347725B2 (en) * 2020-01-14 2022-05-31 EMC IP Holding Company LLC Efficient handling of highly amortized metadata page updates in storage clusters with delta log-based architectures
US11803593B2 (en) * 2020-02-14 2023-10-31 Coupang Corp. Systems and methods for receiving and propagating efficient search updates in real time
US11099956B1 (en) 2020-03-26 2021-08-24 Commvault Systems, Inc. Snapshot-based disaster recovery orchestration of virtual machine failover and failback operations
US11341163B1 (en) 2020-03-30 2022-05-24 Amazon Technologies, Inc. Multi-level replication filtering for a distributed database
US11971855B2 (en) * 2020-05-19 2024-04-30 EMC IP Holding Company LLC Supporting multiple operations in transaction logging for a cloud-enabled file system
CN111597152B (zh) * 2020-05-20 2023-04-21 杭州海康威视系统技术有限公司 固态硬盘文件系统管理方法、装置及电子设备
US11372842B2 (en) * 2020-06-04 2022-06-28 International Business Machines Corporation Prioritization of data in mounted filesystems for FSCK operations
US11494417B2 (en) 2020-08-07 2022-11-08 Commvault Systems, Inc. Automated email classification in an information management system
US11645175B2 (en) 2021-02-12 2023-05-09 Commvault Systems, Inc. Automatic failover of a storage manager
US20220269667A1 (en) * 2021-02-24 2022-08-25 Ronen Grosman Method and system for non-blocking database logging batching
US11934670B2 (en) 2021-03-31 2024-03-19 Netapp, Inc. Performing various operations at the granularity of a consistency group within a cross-site storage solution
US11893261B2 (en) 2021-05-05 2024-02-06 Netapp, Inc. Usage of OP logs to synchronize across primary and secondary storage clusters of a cross-site distributed storage system and lightweight OP logging
US20230032678A1 (en) * 2021-07-29 2023-02-02 Micro Focus Llc Abnormality detection in log entry collection
US11593223B1 (en) 2021-09-02 2023-02-28 Commvault Systems, Inc. Using resource pool administrative entities in a data storage management system to provide shared infrastructure to tenants
US11892982B2 (en) 2021-10-20 2024-02-06 Netapp, Inc. Facilitating immediate performance of volume resynchronization with the use of passive cache entries
US11809285B2 (en) 2022-02-09 2023-11-07 Commvault Systems, Inc. Protecting a management database of a data storage management system to meet a recovery point objective (RPO)
US11726916B1 (en) * 2022-04-27 2023-08-15 EMC IP Holding Company, LLC Method, computer program product, and computing system for defining a normal IO write mode and handling requests to enter a testing IO write mode
US11907562B2 (en) 2022-07-11 2024-02-20 Netapp, Inc. Methods and storage nodes to decrease delay in resuming input output (I/O) operations after a non-disruptive event for a storage object of a distributed storage system by utilizing asynchronous inflight replay of the I/O operations

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH06124223A (ja) * 1991-03-28 1994-05-06 Texas Instr Inc <Ti> ディスクファイルシステムのログ装置および方法
US5715447A (en) * 1991-08-06 1998-02-03 Fujitsu Limited Method of and an apparatus for shortening a lock period of a shared buffer
US5530855A (en) * 1992-10-13 1996-06-25 International Business Machines Corporation Replicating a database by the sequential application of hierarchically sorted log records
US5870757A (en) 1995-09-11 1999-02-09 Sun Microsystems, Inc. Single transaction technique for a journaling file system of a computer operating system
US5778168A (en) 1995-09-11 1998-07-07 Sun Microsystems, Inc. Transaction device driver technique for a journaling file system to ensure atomicity of write operations to a computer mass storage device
JP2000515657A (ja) * 1996-08-02 2000-11-21 トランソフト コーポレイション 共有資源の分散制御を可能にする方法と装置
US5832516A (en) * 1997-01-21 1998-11-03 Oracle Corporation Caching data in recoverable objects
US5897661A (en) * 1997-02-25 1999-04-27 International Business Machines Corporation Logical volume manager and method having enhanced update capability with dynamic allocation of storage and minimal storage of metadata information
US6119208A (en) * 1997-04-18 2000-09-12 Storage Technology Corporation MVS device backup system for a data processor using a data storage subsystem snapshot copy capability
US5897641A (en) * 1997-05-13 1999-04-27 International Business Machines Corporation Application of log records to data compressed with different encoding scheme
US6144999A (en) * 1998-05-29 2000-11-07 Sun Microsystems, Incorporated Method and apparatus for file system disaster recovery
US6185663B1 (en) * 1998-06-15 2001-02-06 Compaq Computer Corporation Computer method and apparatus for file system block allocation with multiple redo
US6341341B1 (en) * 1999-12-16 2002-01-22 Adaptec, Inc. System and method for disk control with snapshot feature including read-write snapshot half

Cited By (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004252933A (ja) * 2002-06-03 2004-09-09 Thomson Licensing Sa メタデータ項目の伝達を制御する方法
US7934195B2 (en) 2002-06-03 2011-04-26 Thomson Licensing Method for controlling the propagation of metadata items
US7640388B2 (en) 2003-10-10 2009-12-29 Sony Corporation File storage apparatus for storing file data and management information
JP2005316635A (ja) * 2004-04-28 2005-11-10 Hitachi Ltd データ処理システムおよび方法並びにその処理プログラム
JP4561168B2 (ja) * 2004-04-28 2010-10-13 株式会社日立製作所 データ処理システムおよび方法並びにその処理プログラム
KR100781515B1 (ko) * 2006-01-10 2007-12-03 삼성전자주식회사 트랜잭션 처리를 위한 로그 정보 관리 시스템 및 방법
JP4699516B2 (ja) * 2006-03-28 2011-06-15 富士通株式会社 名前空間複製プログラム、名前空間複製装置、名前空間複製方法
JP2008040699A (ja) * 2006-08-04 2008-02-21 Fujitsu Ltd Ｈｓｍ制御プログラム、ｈｓｍ制御装置、ｈｓｍ制御方法
WO2012032727A1 (en) * 2010-09-09 2012-03-15 Nec Corporation Storage system
JP2013514561A (ja) * 2010-09-09 2013-04-25 日本電気株式会社 ストレージシステム
US8924663B2 (en) 2010-09-09 2014-12-30 Nec Corporation Storage system, computer-readable medium, and data management method having a duplicate storage elimination function
JP2013250982A (ja) * 2012-06-01 2013-12-12 Samsung Electronics Co Ltd 記憶装置のデータ書き込み方法
CN110719233A (zh) * 2019-10-11 2020-01-21 北京百度网讯科技有限公司 用于发送信息的方法及装置
CN110719233B (zh) * 2019-10-11 2023-10-31 北京百度网讯科技有限公司 用于发送信息的方法及装置
CN113448772A (zh) * 2020-11-23 2021-09-28 北京新氧科技有限公司 一种精细化数据回滚方法及装置
CN113448772B (zh) * 2020-11-23 2023-08-11 北京新氧科技有限公司 一种精细化数据回滚方法及装置

Also Published As

Publication number Publication date
US6732124B1 (en) 2004-05-04
JP3763992B2 (ja) 2006-04-05

Similar Documents

Publication Publication Date Title
JP3763992B2 (ja) データ処理装置及び記録媒体
US6493837B1 (en) Using log buffers to trace an event in a computer system
JP3593366B2 (ja) デ−タベ−ス管理方法
US9021303B1 (en) Multi-threaded in-memory processing of a transaction log for concurrent access to data during log replay
US7266669B2 (en) File system with file management function and file management method
US7107294B2 (en) Method and apparatus for interrupting updates to a database to provide read-only access
JP2679779B2 (ja) トランザクション処理方法及び装置
US5933593A (en) Method for writing modified data from a main memory of a computer back to a database
US7085955B2 (en) Checkpointing with a write back controller
EP1089176A2 (en) Transactional file system for realizing atomic update of plural files by transactions
Ren et al. Low-overhead asynchronous checkpointing in main-memory database systems
JP4916892B2 (ja) トランザクション処理のためのログ情報管理システムおよび方法
JPH07175700A (ja) データベース管理方式
Graefe A survey of B-tree logging and recovery techniques
JP7101566B2 (ja) 不揮発性メモリにおけるマルチバージョン同時実行制御（ｍｖｃｃ）
JPH09503328A (ja) 非同期に順序付けされた動作を行うコンピュータ方法及び装置
US20030028723A1 (en) Efficient data backup using a single side file
JPH0644010A (ja) タイムゼロ・バックアップ・コピー・プロセスにおける副ファイル状態のポーリングのための方法およびシステム
JPH05210555A (ja) ゼロ時間データ・バックアップ・コピーの方法及び装置
JP2009251853A (ja) メモリデータベース、メモリデータベースシステム及びメモリデータベース更新方法
CN113220490A (zh) 异步写回持久化内存的事务持久化方法及系统
JP4189342B2 (ja) ストレージ装置、ストレージコントローラ及びライトバックキャッシュ制御方法
JP4286857B2 (ja) ノード間共用ファイル制御方法
JP3107094B2 (ja) 共用バッファのロック期間短縮処理方法及び装置
JPH0816881B2 (ja) データベース更新方法

Legal Events

Date Code Title Description
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: 20060117

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20060118

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: 20100127

Year of fee payment: 4

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

Free format text: PAYMENT UNTIL: 20110127

Year of fee payment: 5

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

Free format text: PAYMENT UNTIL: 20110127

Year of fee payment: 5

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

Free format text: PAYMENT UNTIL: 20120127

Year of fee payment: 6

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

Free format text: PAYMENT UNTIL: 20130127

Year of fee payment: 7

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

Free format text: PAYMENT UNTIL: 20130127

Year of fee payment: 7

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

Free format text: PAYMENT UNTIL: 20140127

Year of fee payment: 8

LAPS Cancellation because of no payment of annual fees