JPH09114718A - コンピュータ・マス・ストレージ装置への書込み操作のアトミシティを保証するためのジャーナリング・ファイル・システム用トランザクション装置ドライバ技術 - Google Patents

Abstract

(57)【要約】 【課題】 種々の複雑なトランザクション機構を実現す
る必要性なしにデータのアトミシティを保証する。 【解決手段】 ＯＳのファイル・システム（ＦＳ）は、
トランザクション装置（メタトランス）ドライバ３２
に、ＦＳオペレーションの始めと終りと、該始まり以来
発生している重要なデータ更新とについて知らせる。該
ドライバは、データが正常な読出し／書込み／ストラテ
ジ・エントリー点を介して該ドライバに現れる度に更新
をログする。該ドライバは、未処理のオペレーションが
ある間システムが故障したなら、オペレーションに対す
る全部の変化がＦＳに現れるか、何らの変化が現れない
かのいずれかを保証する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、一般に、コンピュ
ータ・オペレーティング・システム（「ＯＳ」）のファ
イル・システム（「ＦＳ」）の分野に関する。特に、本
発明は、システム障害の事象においてコンピュータ・マ
ス・ストレージ装置に対する書込み操作のアトミシティ
（最小単位）（ａｔｏｍｉｃｉｔｙ）を保証するための
ジャーナリング・ファイル・システム用トランザクショ
ン装置ドライバに関する。

【０００２】なお、本発明は、発明の名称が「Single T
ransaction Technique For a Journaling File System
of a Computer Operating System」の米国特許出願Ｓｅ
ｒｉａｌ Ｎｏ．０８／５２６７９０であって、１９９
５年９月１１日に出願され、本発明の譲受人であるＭｏ
ｕｎｔａｉｎ Ｖｉｅｗ，ＣＡのサン・マイクロシステ
ム社（Ｓｕｎ Ｍｉｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．）
に譲渡された当該米国特許出願の主題と関連する。該出
願の開示の内容が本明細書に参照のため特別に組み込ま
れている。

【０００３】

【従来の技術】ディスク・ドライブのようなコンピュー
タ・マス・ストレージ装置は、システム障害が「書込
み」操作中に生じた場合データのアトミシティを保証す
ることができないので、従来のジャーナリング・ファイ
ル・システムは補償するための複雑なトランザクション
機構を用いなければならない。ディスク書込み操作中の
システム障害は、通常、新旧のデータの非決定的混合体
（ｍｉｘ）がディスクに書込まれ、次いでその結果コン
ピュータ・システムのリブートで出会ってしまうことが
生じる。

【０００４】

【発明が解決しようとする課題】従って、上記のこと
は、種々の複雑なトランザクション機構を実現する必要
性なしにデータのアトミシティを保証することができる
ならば非常に望ましい。

【０００５】

【課題を解決するための手段】本発明のジャーナリング
・ファイル・システムのためのトランザクション装置ド
ライバ技術は、従来のジャーナリング・ファイル・シス
テムの要件に対して適合されるトランザクション・イン
ターフェースをエクスポート（ｅｘｐｏｒｔ）すること
によりシステム障害の事象においてコンピュータ・マス
・ストレージ装置に対する書込み操作のアトミシティを
保証する点で特別に有益である。本明細書において開示
される特定の実施形態においては、ＯＳファイル・シス
テムは、トランザクション装置ドライバにファイル・シ
ステム・オペレーションが始まりそして終わるときを通
知する。オペレーション中、ファイル・システムはま
た、トランザクション・ドライバに、ファイル・システ
ム・オペレーションの始まり以来生じている重要なデー
タの更新について通知する。本明細書において開示され
るトランザクション装置ドライバは、データが正常な読
出し／書込み／ストラテジ・エントリー・ポイントを介
してドライバの中へ現れるとき、更新をログする。

【０００６】未決着のオペレーションがある間にシステ
ムが障害を起こす場合、トランザクション装置ドライバ
は、オペレーションについての全部の変化がファイル・
システムに現れるか、変化が何も現れないかのいずれか
を保証する。その結果、ディスクに書込まれ且つリブー
トで出会うデータは、全部新しいデータと全部古いデー
タの双方は非決定的に混合されずに全部新しいデータ
か、全部古いデータかのいずれかである。

【０００７】本明細書において開示されるトランザクシ
ョン装置ドライバの恩恵の一つは、既存のコード・パス
が損なわれないままであるが、開示されるジャーナリン
グの機能性がいずれのＵＮＩＸ（ユニックス）（登録商
標）又は関連のＯＳファイル・システムにトランザクシ
ョン装置ドライバへの数個のコールを有して容易に加え
られることである。更に、特定の実施形態において、追
加のトランザクション・コードが、メンテナンス及び試
験機能を高めるため相対的に局所化される。その上、何
ら新しい相互作用が、ファイル・システム・サブシステ
ム、仮想メモリー・サブシステム及びディスク-バッフ
ァー・キャッシュ・サブシステムとの間に導入されず、
そのため性能、安定性及び保全性を増大させる。最終的
には、ファイル・システムに作用するユーティリティは
変わらないままであり得る。本発明のトランザクション
装置ドライバなしでは、例えばファイル・システム・チ
ェック（「ｆｓｃｋ」）、「ダンプ（ｄｕｍｐ）」、
「クォータチェック（ｑｕｏｔａｃｈｅｃｋ）」のよう
な従来のユーティリティは、ファイル・システムとファ
イル・システムのジャーナル又はログとの双方を処理し
なければならない。

【０００８】本発明は、ＵＦＳ層又はその等価なものを
組み込んでいるいずれのＳｙｓｔｅｍ ＶベースのＵＮ
ＩＸ（登録商標）ＯＳ、ＩＢＭ ＡＩＸ（登録商標）、
又はマイクロソフト・ウインドウズＮＴ（登録商標）オ
ペレーティング・システムを含むＯＳファイル・システ
ムへジャーナル又はログを加えることにより、一部実施
される。ジャーナルは、アトミック・トランザクション
にグループ化された一連のファイル・システム更新を含
み、新しいタイプのメタデバイス（ｍｅｔａｄｅｖｉｃ
ｅ）即ちメタトランス（ｍｅｔａｔｒａｎｓ）装置によ
り管理される。ジャーナルをオペレーティング・システ
ムへ加えることは、より早いリブートと早い同期書込み
（例えば、ネットワーク・ファイル・システム（「ＮＦ
Ｓ」）、Ｏ ＳＹＮＣ及びディレクトリ更新）とを提供
する。

【０００９】本明細書に開示される特定の実施形態にお
いて、本発明は、ログの使用を通してより早い同期オペ
レーション及びより早いリブートを提供するＵＦＳファ
イル・システムへの拡張として有利に実施される。ファ
イル・システム更新がファイル・システム自体に与えら
れる前に、該ファイル・システム更新はログに安全に記
録される。設計は、対応する上部層及び下部層となるよ
う実施され得る。上部層で、ＵＦＳファイル・システム
は、ファイル・システム更新を記録する下部層へのコー
ルにより修正される。下部層は疑似装置、即ちメタトラ
ンス装置から成り、それはログの内容を管理する責任を
負う。

【００１０】メタトランス装置は、２つのサブデバイ
ス、ロギング装置及びマスター装置から成る。ロギング
装置はファイル・システム更新のログを含み、一方マス
ター装置はファイル・システム自体を含む。個別のロギ
ング装置の存在は、ユーザのプログラム・コードに対し
て見えず、また大部分のカーネルに対して見えない。メ
タトランス装置は、従来のブロック及び生（ｒａｗ）イ
ンターフェースを提供し、通常のディスク装置のように
振る舞う。

【００１１】従来のＯＳアプローチを利用すると、シス
テムのシャットダウンは進行中のシステム・コールを中
断し、それにより一貫性のなさ（以下「非一貫性」とい
う。）を導入し得るので、ファイル・システム（複数）
は、それらを用いることができる前に、チェックされね
ばならない。最初にファイル・システムをチェックする
ことなしにファイル・システムをマウントし且ついずれ
の非一貫性を修復することは、「パニック」即ちデータ
の破壊を生じさせ得る。チェックはファイル・システム
のメタデータを読出して検証することを必要とするの
で、チェックは大きなファイル・システムにとって比較
的遅いオペレーションである。本発明を利用すると、未
完成のシステム・コールからの変化が棄てられるので、
ファイル・システムをブート時にチェックする必要がな
い。その結果、オン-ディスク・ファイル・システム・
データ構造は常に一貫性が保たれること、即ち該構造は
無効のアドレス又は値を含まないことが保証される。唯
一の例外は、システムが破壊する一方、ディレクトリ・
エントリーなしでオープンしているがリンク解除された
ファイルがあるならば、フリー・スペースが一時的に失
われるかも知れないことである。カーネル・スレッドは
最終的にこのスペースを再利用（ｒｅｃｌａｉｍ）す
る。

【００１２】本発明はまた、同期書込み性能を、書込み
操作の数を低減してディスク・シーク時間を排除するこ
とにより改善する。デルタ（複数）がファイル・システ
ム・ブロック全体を再書込みするよりむしろログに記録
されるので、書込みはより小さい。更に、関連の更新が
単一の書込み操作に一緒にグループ化されるので、ブロ
ックが一層少なくなる。ログへの書込みが順次的である
ので、ディスク・シーク時間は著しく低減される。

【００１３】本発明の特定の実施形態に関して本明細書
に記述されるように、ＵＦＳオンディスク・フォーマッ
トが維持され、またロギングを既存のＵＦＳファイル・
システムへ加えるための変更が必要とされず、その結果
該ログが標準のＵＦＳへ戻るため除去され得る。更に、
ＵＦＳユーティリティは以前のように動作し続け、ファ
イル・システムはブート時に一貫性についてチェックさ
れる必要がない。ドライバは、ログを走査し、そこに記
録されたいずれの完了したトランザクションを表すため
ログの内部状態を再構築しなければならない。ログを走
査するのに費やす時間は、ログ装置のサイズに依存する
が、ファイル・システムのサイズには依存しない。合理
的に予見し得る形態の選択のため、ファイル・システム
容量のギガバイト当たり平均１〜１０秒の走査時間に出
会い得る。

【００１４】ファイル・システム更新が一緒にグループ
化されロギング装置に順次書込まれるので、ＮＦＳ書込
み、及びＯ ＳＹＮＣによりオープンされたファイルへ
の書込みは一層早くなる。これは、より少ない書込み
と、シーク時間が大きく低減することを意味する。著し
く改善されたスピードアップは、中央処理装置（「ＣＰ
Ｕ」）のオーバーヘッドのほぼ５０％以上を費やせば期
待し得る。また、ファイル・システム更新が一緒にグル
ープ化されロギング装置に順次書込まれるので、ＮＦＳ
ディレクトリ・オペレーションは一層早くなる。更新の
ロギングがｓｙｎｃ（）、ｆｓｙｎｃ（）、又は同期フ
ァイル・システム・オペレーションまで任意に遅延され
得るので、ローカルなオペレーションもまたより早くな
る。ロギング装置が存在しないならば、ディレクトリ・
オペレーションは通常のように同期して完了し得る。

【００１５】マスター又はロギング装置への書込みが進
行中である間にパワー故障が発生するならば、最後のデ
ィスク・セクターに書込まれた内容が予測不可能であ
り、そして読出し不能ですらあり得る。本発明のログ
は、ファイル・システムのメタデータがこれらの状況下
で失われないように設計される。即ち、ファイル・シス
テムは、パワー故障にも拘わらず一貫性を維持する。本
明細書において詳細に説明される特定の実施形態におい
て、ユーザは、標準のＭＤＤユーティリティを用いてメ
タトランス装置をセットアップして管理し得る一方、ｍ
ｅｔａｉｎｉｔ（ｌｍ）、ｍｅｔａｐａｒａｍ（ｌｐ）
及びｍｅｔａｓｔａｔ（ｌｍ）コマンドは小さい拡張を
有する。従って、学習のための新しいインターフェース
がなく且つマスター装置及びロギング装置が一緒に単一
のディスク装置のように振る舞うので、使用は単純化さ
れる。更に、２以上のＵＦＳファイル・システムが同一
のロギング装置を同時に使用できる。これは、システム
管理を或る状況で単純化する。

【００１６】従来のＵＦＳの実施においては、ファイル
・システムはディスク・パーティションを占有し、ファ
イル・システム・コードは読出し及び書込みコマンドを
ディスクのための装置ドライバへ発行することにより更
新を実施する。本発明の拡張により、ファイル・システ
ム情報はメタトランス装置と呼ばれる論理装置に格納さ
れ得て、その場合、カーネルは、ディスク・ドライバの
代わりにメタトランス・ドライバと通信する。既存のＵ
ＦＳファイル・システム及び装置は変化なしに使用され
続け得る。

【００１７】本発明の前述及び他の特徴及び目的及びそ
れらを達成する要領は、添付の図面と関連する好適実施
形態の以下の記述を参照することにより、より一層明ら
かになり、本発明自体が最良に理解されるであろう。

【００１８】

【発明の実施の形態】本発明が用いられる環境は、一般
の分散コンピューティング・システムであって、汎用コ
ンピュータ、ワークステーション、又はパーソナル・コ
ンピュータが、クライアントサーバー構成において種々
のタイプの通信リンクを介して接続され、そこにおいて
プログラム及びデータ、多くはオブジェクトの形態であ
るが、これらが、システムの他のメンバーにより実行及
びアクセスされるためシステムの広範囲のメンバーによ
り利用される分散コンピューティング・システムを含
む。汎用ワークステーション・コンピュータの一部の要
素が図１に示され、プロセッサ１は入力／出力（「Ｉ／
Ｏ」）セクション２と、中央処理装置（「ＣＰＵ」）３
と、メモリー・セクション４とを有するよう示されてい
る。Ｉ／Ｏセクション２は、キーボード５、ディスプレ
イ・ユニット６、ディスク記憶ユニット９及びコンパク
ト・ディスク読出し専用メモリー（「ＣＤＲＯＭ」）ド
ライブ・ユニット７と接続されている。ＣＤＲＯＭユニ
ット７は、通常プログラム１０及びデータを含むＣＤＲ
ＯＭ媒体８を読出すことができる。本発明の装置及び方
法を実行するための機構を含むコンピュータ・プログラ
ム製品が、かかるシステムのメモリー・セクション４
に、又はディスク記憶ユニット９上に、又はＣＤＲＯＭ
媒体８上に存在し得る。

【００１９】ここで図２を参照するに、本発明を実施す
るためのアーキテクチャ２０を単純化して表した図が、
例えば、ユーザ（又はシステム・コール）層２２とカー
ネル２４とを有するＳｙｓｔｅｍ ＶベースのＵＮＩＸ
オペレーティング・システムと関連して示されている。
以下により十分に説明されるであろうユーザ層２２（即
ち、ＭＤＤ３及びマウント・ユーティリティ２８）及び
カーネル２４（即ち、ＵＦＳ層３０）の部分の修正によ
り、本発明は、メタトランス・ドライバ３２の形態のメ
タトランス層２６に、トランザクション層３４、ロール
・コード３６、回復コード３８及び関連のログ（又は、
ジャーナル）・コード４０を追加することにより主とし
て実施される。

【００２０】ＭＤＤ３ユーティリティは、メタトランス
・ドライバ３２を管理し、その状態をセット・アップ
し、ティア・ダウン（ｔｅａｒ ｄｏｗｎ）し、且つ与
える。マウント・ユーティリティは、遅延されたディレ
クトリー更新の機能（ｆｅａｔｕｒｅ）をディスエーブ
ルする新しい機能（ｆｅａｔｕｒｅ）（「−ｓｙｎｃｄ
ｉｒ」）を含む。ＵＦＳ層３０は、メタトランス・ドラ
イバ３２と、マウントで、及びマウント解除（ｕｎｍｏ
ｕｎｔ）で、及びファイル・システムのシステム・コー
ルをサービスするときにインターフェースする。主要な
メタトランス・ドライバ３２はベースＭＤＤ３ドライバ
とインターフェースし、トランザクション層３４は、主
要なメタトランス・ドライバ３２とインターフェース
し、またＵＦＳ層３０とインターフェースする。ロール
・コード３６は、完了されたトランザクションをマスタ
ー装置へロールし、またメタトランス・ドライバ３２の
種々のピース（ｐｉｅｃｅｓ）からデータを組み合わせ
ることにより読出しリクエストを満足させる。回復コー
ドは、以下でより十分に説明されるように、ログを走査
し、ログ・マップを再作成し、一方ログ・コードは、バ
イト・ストリーム装置を備えるオペレーティング・シス
テムの上部層を提供し、部分的なディスク・ドライブ書
込み操作を検出する。

【００２１】ここで更に図３を参照すると、本発明のア
ーキテクチャの主要構成要素が非常に詳細に示されてい
る。ＵＦＳ層３０は、ＶＯＰ又はＶＦＳインターフェー
ス４２を介してエンターされる。ＵＦＳ層３０は、ファ
イル・システムのデータのインコア・コピー（ｉｎｃｏ
ｒｅ ｃｏｐｉｅｓ）を変えることによりファイル・シ
ステムを変える。インコア・コピーはバッファー又はペ
ージ・キャッシュ４１に保持される。インコア・コピー
に対する変化は、デルタ（複数）４３と呼ばれる。ＵＦ
Ｓは、トランスオプス（ｔｒａｎｓｏｐｓ）・インター
フェース４５をメタトランス装置３２に対して用いるこ
とにより、メタトランス・ドライバ３２にどのデルタ４
３が重要であるかを告げる。

【００２２】ＵＦＳ層は各デルタ４３後の書込みを強制
しない。そうするのは著しい性能の損失であろう。代わ
りに、変えられたバッファー及びページが、デルタ４３
を生じさせたＶＯＰ又はＶＦＳインターフェース４２の
コールの終わりで通常のシステム活動により、又はＩＴ
Ｓによりプッシュされる。概略図示されているように、
メタトランス・ドライバ３２は、カーネル２４の上部層
に対する単一ディスク装置のように見える。内部的に
は、メタトランス・ドライバ３２は、２つのディスク装
置、即ちマスター装置４４とログ装置４６とから構成さ
れている。メタトランス装置３２への書込みがマスター
装置４４へｂｄｅｖ ｓｔｒａｔｅｇｙを介して通され
るか、又はデルタ４３がリクエストに抗してトランスオ
プス・インターフェース４５を介して記録されてしまっ
た場合データの変えられた部分が書込みバッファー５０
の中にコピーされ、ログ・スペースを割り当てられ、リ
クエストがバイオダンド（ｂｉｏｄｏｎｅ’ｅｄ）され
るかいずれかである。デルタ４３は、デルタ・マップ４
８からログ・マップ５４へこのプロセスにおいて移動さ
れる。

【００２３】ＩＴＳがＶＯＰ又はＶＦＳ層４２のコール
の終わりでコミット（図示せず）を発行するとき、又は
書込みバッファー５０が一杯になるとき、書込みバッフ
ァー５０はログ装置４６へ書込まれる。どのＶＯＰ又は
ＶＦＳ層４２のコールもコミットを発行するわけではな
い。ファイル（オープンされてないＯ ＳＹＮＣ（＊ｎ
ｏｔ＊ ｏｐｅｎｅｄ Ｏ ＳＹＮＣ））へのルックア
ップ又は書込みのような或るトランザクションは、書込
みバッファー５０において単一トランザクションとして
単純に収集する。

【００２４】読出しのためのデータが書込みバッファー
５０、読出しバッファー５２、マスター装置４４及びロ
グ装置４６のうちのいずれの組み合わせからも来ること
ができるので、メタトランス装置３２を読出すことはや
や複雑である。コミットされたデルタ４３からデータを
前方のマスター装置４４へローリングすることは、マス
ター装置４４への「書込み」が続く「読出し」として一
般に見える。相違は、データがまたバッファー又はペー
ジ・キャッシュ４１から来ることができることである。
影響されたデルタ４３はログ・マップ５４から除去され
る。ロール／読出しコード・ブロック５６は、マスター
装置４４及びログ装置４６へ、同様に書込みバッファー
５０及び読出しバッファー５２へ結合され、バッファー
又はページ・ドライバ５８とインターフェースする。

【００２５】ここで図４を参照するに、ブート・プロセ
スの早期に、オンライン：ディスクスート（Ｏｎ−ｌｉ
ｎｅ：Ｄｉｓｋｓｕｉｔ）（「ＯＤＳ」）状態データベ
ースが走査され、メタデバイスについてのインコア（ｉ
ｎｃｏｒｅ）状態が再び生成されることが分かる。各メ
タデバイスは、ユニット構造により表され、メタトラン
ス装置についてのユニット構造は、そのロギング装置ユ
ニット構造のアドレスを含み、またその逆でもある。メ
タトランス装置６０ユニット構造は、ｍｔ ｕｎｉｔ
ｔであり、ｍｄ ｔｒａｎｓ．ｈにおいて定義される。
ロギング装置６２ユニット構造は、ｍｌ ｕｎｉｔ ｔ
であり、またｍｄ ｔｒａｎｓ．ｈにおいて定義され
る。

【００２６】ここで図５を更に参照するに、ロギング装
置６２ユニット構造は、ｕｌ ｌｉｓｔによりアンカー
されたグローバルなリンクされたリストについて維持さ
れる。ロギング装置６２を共用するメタトランス装置６
０についてのメタトランス装置６０ユニット構造の各々
は、ロギング装置のユニット構造によりアンカーされる
リンクされたリスト上に保持される。

【００２７】図６を更に参照するに、ユニット構造がセ
ット・アップされた後に、走査スレッドが各ロギング装
置６２に対して開始される。走査スレッドは、ログ装置
６２を走査しそのロギング装置６２のためのログマップ
６４を再作成するカーネル・スレッドである。ログマッ
プ６４はｍｔ ｍａｐ ｔであり、ｍｄ ｔｒａｎｓ．
ｈにおいて定義される。ログマップ６４は、マスター装
置へロールされるのに必要であるログにおいて各デルタ
４３に対してｍａｐｅｎｔｒｙ ｔを含む。マップ・エ
ントリー６８は、読出し操作中の早いルックアップのた
めハッシュ・アンカー６６（メタトランス装置、メタト
ランス装置オフセット）によりハッシュされる。性能を
向上させるため、マップ・エントリー（複数）６８はま
た、それらがロール・インされるべき順序でリンクされ
たリストについて維持される。図７に概略図示されてい
るように、メタトランス装置６０及びロギング装置６２
のためのユニット構造は、ログマップ６４（図３におけ
るログ・マップ５４）のアドレスを含み、該アドレス
は、ハッシュされたマップエントリー７０と全部のマッ
プエントリー７２と関連される。

【００２８】ここで図８をも参照するに、デルタマップ
７４が各メタトランス装置６０と関連されている。デル
タマップ７４は、ファイル・システム・オペレーション
を備える変化についての情報を格納する。ファイル・シ
ステムは、タプル（マスター装置４４についてのオフセ
ット、データのバイトの番号及びコールバック）を装置
により記録することにより、メタトランス装置６０に上
記の変化（あるいはデルタ４３）について知らせる。メ
タトランス装置６０は、ハッシュ・アンカー７６と共
に、デルタマップ７４（図３におけるデルタ・マップ４
８）に格納されている各デルタ４３に対してマップエン
トリー７８を生成する。デルタマップ７４は、ログマッ
プ６４（図６〜図７）に似たｍｔ ｍａｐ ｔであり、
同じストラクチャを有する。

【００２９】図９をも参照するに、トランザクションの
終わりで、各マップ・エントリー６８でもって記録され
たコールバックが、ログされたデータを含む「書込み」
の場合呼び出される。コールバックは、デルタ４３と関
連したデータが書き込まれるようにするファイル・シス
テムにおける機能である。この「書込み」が、メタトラ
ンス・ドライバに現れると、ドライバは、書込まれてい
るバッファー８０とデルタマップ７４の中のデルタ４３
との間のオーバーラップを検出する。オーバーラップが
ないならば、書込みは、マスター装置４４（図３）上へ
通される。オーバーラップが検出されるならば、オーバ
ーラップするマップ・エントリーが、デルタマップ７４
から除去され、下方のログマップ層へ通される。

【００３０】ログマップ層は、デルタ４３＋データをロ
グの書込みバッファー５０に格納し、マップ・エントリ
ーをログマップ６４の中に置く。デルタ４３についての
データがトランザクションの終わりの前に書込まれてし
まい、そして、もしそうならば、同じプロセスが続くこ
とに注目すべきである。一度データがログの書込みバッ
ファー５０にコピーされると、バッファーはアイオダン
ド（ｉｏｄｏｎｅ’ｅｄ）される。

【００３１】デルタマップ７４についてｍｔ ｍａｐ
ｔアーキテクチャを用いる理由の一つは、ドライバがｋ
ｍｅｍ ａｌｌｏｃを用いることができないことであ
る。ログマップに現れ得る各エントリーに対するメモリ
ーは、バッファーがドライバに現れる前に割り当てられ
ることが必要である。デルタマップ７４のデルタ４３と
ログマップ６４のエントリーとの間に１対１の対応があ
るので、デルタマップ・エントリー７８がログマップ・
エントリー６８と同じであるべきことは明らかである。

【００３２】ここで図１０を参照するに、ログされたデ
ータを含む「読出し」の類似の状況が示されている。分
かり得るように、ログマップ６４はまた、読出し操作の
ため用いられる。読出されているバッファーがログマッ
プ６４のいずれのエントリー６８ともオーバーラップし
ないならば、「読出し」は、下方のマスター装置４４へ
単純に通される。他方、バッファーがログマップ６４の
中のエントリー６８とオーバーラップするならば、バッ
ファーに対するデータは、マスター装置４４からのデー
タとロギング装置４６からのデータとの組み合わせであ
る。

【００３３】図１１及び図１２を参照するに、マウント
時での状況が概略的に示されている。ブート・プロセス
の早期に、各メタトランス装置は、自身をＵＦＳファン
クションｕｆｓ ｔｒａｎｓ ｓｅｔにより記録し、ｕ
ｆｓｔｒａｎｓストラクト（構造体）（ｕｆｓｔｒａｎ
ｓ ｓｔｒｕｃｔ）８４を生成し、それをグローバルな
リンクされたリストにリンクする。マウント時に、ファ
イル・システムは、ｕｆｓｔｒａｎｓストラクト（ｕｆ
ｓｔｒａｎｓ ｓｔｒｕｃｔ）８６に格納されたｄｅｖ
ｔ（複数）に対してファイル・システムのｄｅｖ ｔ
をチェックする。整合がある場合、ファイル・システム
は、ｕｆｓｔｒａｎｓストラクト８６のアドレスをその
ファイル・システムの特別のパーマウント・ストラクト
（ｐｅｒ−ｍｏｕｎｔ ｓｔｒｕｃｔ）ｕｆｓｖｆｓ９
０に格納する。ファイル・システムはまた、その総称的
なパーマウント・ストラクトｖｆｓ８８をｕｆｓｔｒａ
ｎｓストラクト８６に格納する。この活動は、ｍｏｕｎ
ｔｆｓ（）により、またｕｆｓ ｔｒａｎｓ ｇｅ
ｔ（）により達成される。ｖｆｓ８８のアドレスは、ア
ドレスが種々のコールバック機能により要求されること
のため、ｕｆｓｔｒａｎｓストラクト８６に格納され
る。

【００３４】ファイル・システムは、メタトランス・ド
ライバ３２（図２〜図３）とｕｆｓｔｒａｎｓｏｐｓ９
２ストラクト（ｓｔｒｕｃｔ）においてエントリー・ポ
イントを呼出すことにより通信する。これらのエントリ
ー・ポイントは、始めオペレーション、終わりオペレー
ション及びデルタ記録機能を含む。共に、これらの３つ
の機能は、ＵＦＳ層３０オペレーションをトランザクシ
ョンするために必要とされる大量の作業を実施する。図
１３は、先の図面に示され以下で更に十分に説明される
ような本発明のデータ構造の要約を提供する。

【００３５】メタトランス装置、即ちメタトランス・ド
ライバ３２は、下に在る２つの装置、即ちロギング装置
４６とマスター装置４４とを含む。これらの双方はディ
スク装置又はメタデバイスであり得る（しかしメタトラ
ンス装置ではない）。双方は、メタトランス・ドライバ
の制御の下にあり、ユーザ・プログラム又はシステムの
他のパーツにより一般に直接アクセス可能ではない。ロ
ギング装置４６はジャーナル又はログを含む。ログは一
連の記録であり、その記録の各々はファイル・システム
（デルタ４３）への変化を記述する。カレント（ｃｕｒ
ｒｅｎｔ）・アクティブ・ｖノード（ｖｎｏｄｅ）・オ
ペレーションと対応するデルタ４３の組はトランザクシ
ョンを形成する。トランザクションが完了すると、コミ
ット記録がログに置かれる。システムが破壊するなら
ば、ログに含まれたいずれのコミットされないトランザ
クションはリブートの際棄てられる。ログはまた、（例
えばＮＦＳにより）同期書込みされてしまったユーザ・
データを含み得る。このデータをロギングすることは、
ファイル・システムの性能を改善するが、強制的ではな
い。十分なログ・スペースが利用できないならば、ユー
ザ・データはマスター装置４４へ直接書込まれ得る。マ
スター装置４４は、標準フォーマットのＵＦＳファイル
・システムを含む。ファイル・システムを既に含む装置
がマスター装置４４として用いられるならば、ファイル
・システムの内容は保存され、その結果、標準のＵＦＳ
から本発明の拡張へのアップグレードは直接的である。
メタトランス・ドライバは、マスター装置４４を、完了
されたトランザクション及びユーザ・データにより更新
する。ｍｅｔａｃｌｅａｒ（ｌｍ）はメタトランス装置
３２をディゾルブ（ｄｉｓｓｏｌｖｅ）し、その結果、
マスター装置４４は、所望ならば、標準ＵＦＳと共に再
び用いられ得る。

【００３６】メタトランス装置３２は、従来の生（ｒａ
ｗ）インターフェース及びブロック・インターフェース
を提供し、通常のディスク装置のように振る舞う。個別
のトランザクション・インターフェースは、ファイル・
システム・コードがファイル・システム更新をドライバ
へ通信することを可能にする。装置の内容は、マスター
装置４４の内容でログに記録されたデルタ４３により修
正されたものから成る。

【００３７】トランザクション・インターフェースを通
して、ＵＦＳは、ドライバに、何のデータがカレント
（ｃｕｒｒｅｎｔ）・トランザクション（例えば、ｉノ
ード修正時間）において変わりつつあるかと、トランザ
クションが終了されるときとを知らせる。ドライバは、
更新されたデータを含むログ記録を構成し、それらをロ
グへ書込む。ログが十分に一杯になると、ドライバはそ
れを前方へロールする。ログ・スペースを再使用するた
め、ログに記録された完了されたトランザクションはマ
スター装置４４へ与えられねばならない。トランザクシ
ョンにより修正されたデータがメモリーの中のページ又
はバッファーにおいて利用可能であるならば、メタトラ
ンス・ドライバはそれをマスター装置４４へ単純に書込
む。さもなければ、データは、メタトランス装置３２か
ら読出されねばならない。ドライバは、オリジナル・デ
ータをマスター装置４４から読出し、次いでデルタ４３
をログから読出し、更新されたデータをマスター装置４
４へ戻して書込む前にそれらオリジナル・データ及びデ
ルタ４３を与える。本発明の譲受人であるＳｕｎ Ｍｉ
ｃｒｏｓｙｓｔｅｍｓ，Ｉｎｃ．により開発されライセ
ンスが与えられたＳｕｎＯＳ（登録商標）の有効なキャ
ッシングが、後者のケースをほんの稀に生じさせ、大部
分の場合、ログが順次書込まれ、少しも読出されない。

【００３８】後続のオペレーションがそれらの効果を無
効にする（ｎｕｌｌｉｆｙ）ので、ＵＦＳはまた先のデ
ルタ４３を取り消し得る。この取り消しは、メタデータ
のブロック、例えば割当てブロックがフリーにされ、そ
の結果ユーザ・データとして再配置されるとき必要であ
る。取り消しなしに、古いメタデータに対する更新がユ
ーザ・データに対して誤って与えられるかも知れない。

【００３９】メタトランス・ドライバは、ログの内容の
トラックを保ち、そのスペースを管理する。それは、ト
ランザクション及びデルタ４３についてのデータ構造を
維持し、ログ記録をマスター装置４４のロケーションと
関連させるマップを保持する。システムが破壊するなら
ば、これらの構造は、装置が用いられる（しかしコミッ
トされないトランザクションは無視される）次の時間に
ログから再構成される。ログ・フォーマットは、部分的
に書込まれた記録又は未使用のログ・スペースが有効な
トランザクション情報に対して間違えられることができ
ないことを保証する。カーネル・スレッドは、ログを走
査してメタトランス装置３２についての最初の読出し又
は書込みの際マップを再構成するため生成される。デー
タ転送は、Ｉ／Ｏを必要としないドライバ・オペレーシ
ョンが処理し得るにも拘わらず、カーネル・スレッドが
完了するまで中止される。

【００４０】本発明の主要な便益の１つは、メタデータ
をパワー故障による破壊に抗して保護することである。
これは、メタトランス・ドライバがパワー故障時にデル
タ４３をマスター装置４４に与えている場合ログの内容
に拘束を課する。この場合、更新されつつあるファイル
・システム・オブジェクトは、部分的に書込まれ、又は
破壊すらされ得る。ログからのオブジェクトの全体の内
容は、依然回復されねばならない。これを達成するた
め、ドライバは、オブジェクトがマスター装置４４に書
込まれる前にオブジェクトのコピーがログにあることを
保証する。

【００４１】メタトランス装置３２は、他の種類の媒体
障害を訂正することを試みない。例えば、ロギング装置
４６の書込み又はその読出し中の装置エラーは、メタト
ランス装置３２を例外の状態に置く。メタトランス装置
３２の状態は、ＭＤＤデータベースに保持される。エラ
ーが発生するときとそのエラーの種類とに基づく種々の
例外状態がある。

【００４２】メタトランス・ドライバ３２の構成は、標
準のＭＤＤユーティリティを用いて実施され得る。ＭＤ
Ｄの動的な連結機能（ｆｅａｔｕｒｅ）はマスター装置
４４及びロギング装置４６の双方の動的な拡張を可能に
する。装置の構成及び他の状態情報は、ＭＤＤ状態デー
タベースに格納され、該データベースは複写及び持続性
をリブートにまたがって提供する。情報を格納するのに
必要とされるスペースは比較的小さく、メタトランス装
置３２当たり１ディスク・セクターのオーダーである。

【００４３】本発明の特定の実施においては、ＵＦＳ
は、ファイル・システムがメタトランス装置３２上にマ
ウント時に存在するかをｕｆｓ ｔｒａｎｓ ｇｅ
ｔ（）を呼び出すことによりチェックする。ファイル・
システムがメタトランス装置３２上にないならば、この
機能はヌル（ＮＵＬＬ）を返し、さもなければ、該機能
はメタトランス装置３２を識別するハンドルを返す。こ
のハンドルは、後続のトランザクション・オペレーショ
ンにおいて使用のためマウント構造にセーブされる。フ
ァンクションＴＲＡＮＳ ＢＥＧＩＮ（）及びＴＲＡＮ
Ｓ ＥＮＤ（）は、トランザクションの始めと終わりを
指示する。ＴＲＡＮＳ ＤＥＬＴＡ（）はログされねば
ならないファイル・システムに対する変化を識別する。
ＴＲＡＮＳ ＣＡＮＣＥＬ（）は、ファイル・システム
・データ構造がリサイクルされつつある又は棄てられつ
つあるので先にログされたデルタ４３が取り消されるべ
きであることを指示する。

【００４４】ファイル・システム・チェック（「ｆｓｃ
ｋ」）・ユーティリティが本発明に従ってファイル・シ
ステム上でランされるとき、該ファイル・システム・チ
ェック・ユーティリティは、スーパーブロックの中のフ
ァイル・システムのクリーン・フラグをチェックし、フ
ァイル・システム装置をｉｏｃｔｌコマンドを介して問
い合わせる。スーパーブロックと装置の双方が、ファイ
ル・システムがメタトランス装置３２上にあることに同
意し且つ装置がいずれの例外状態を報告しないとき、ｆ
ｓｃｋは更なるチェッキングをスキップすることができ
る。さもなければ、ｆｓｃｋはファイル・システムを従
来の要領でチェックする。

【００４５】「クォータチェック（ｑｕｏｔａｃｈｅｃ
ｋ）」ユーティリティが本発明に従ってファイル・シス
テム上でランされるとき、該ユーティリティは、スーパ
ーブロックの中のシステムのクリーン・フラグをチェッ
クし、ファイル・システム装置をｉｏｃｔｌコマンドを
介して問い合わせる。スーパーブロックと装置の双方
が、ファイル・システムがメタトランス装置３２上にあ
ることに同意し且つ装置がいずれの例外状態を報告しな
いとき、クォータチェックはクォータ（ｑｕｏｔａ）・
ファイルを再作成する必要がない。さもなければ、クォ
ータチェックは、従来の要領でファイル・システムのた
めクォータ・ファイルを再作成する。

【００４６】本発明のロギング機構は、失われたフリー
・スペースを除いて、ファイル・システムの一貫性を保
証する。ファイル・システムが下へ行くときオープンし
ているが削除されるファイルがある（即ち、いずれのデ
ィレクトリ・エントリーにより言及されない）ならば、
これらのファイルによりクレーム（ｃｌａｉｍ）された
ファイル・システム資源は一時的に失われる。カーネル
・スレッドは、これらの資源をサービスを中断すること
なく再利用（ｒｅｃｌａｉｍ）する。性能の最適化とし
て、ファイル・システムのスーパーブロックにおける先
に未使用のフィールドｆｓ ｓｐａｒｅｃｏｎ［５３］
は、この種のいずれかのファイルが存在するかを指示す
る。所望ならば、ｆｓｃｋは、失われたスペースを直ち
に再利用することができ、ｆｓ ｓｐａｒｅｃｏｎ［５
３］はｆｓ ｒｅｃｌａｉｍと名前が付け直される。

【００４７】ディレクトリが、ローカルなアプリケーシ
ョンにより、あるいはクライアント−サーバー・コンピ
ュータ・システムにおける遠隔のクライアントのためラ
ンするデーモンにより変化させられ得る。標準のＵＦＳ
インプリメンテーションにおいて、遠隔の及びローカル
の双方のディレクトリの変化は同期してなされ、即ちデ
ィレクトリへの更新は、リクエストがアプリケーション
又はデーモンに戻る前にディスクに書込まれる。ローカ
ルなディレクトリ・オペレーションは同期しており、そ
のためファイル・システムは、ブート時に自動的に修復
され得る。ＮＦＳプロトコルは、同期ディレクトリ・オ
ペレーションを必要とする。本発明の技術を用いて、遠
隔のディレクトリの変化は、同期してなされるが、しか
しローカルなディレクトリの変化は、メモリーに保持さ
れ、ｓｙｎｃ（）、ｆｓｙｎｃ（）又は同期ファイル・
システム・オペレーションがそれらの変化を追い出すま
でログへ書込まれない。その結果、システムが破壊する
がしかしファイル・システムは一貫性の有る状態のまま
であるならば、ローカルなディレクトリの変化を失うこ
とができる。ローカルなディレクトリの変化は命令され
たままである。

【００４８】ローカルなディレクトリの更新をメモリー
の中に保持することは性能を非常に改善する。これは、
完了されたディレクトリ・オペレーションが今消滅しシ
ステムの破壊が続くかも知れないので、ファイル・シス
テムの意味（ｓｅｍａｔｉｃｓ）に変化を導入する。し
かしながら、古い振る舞いは、いずれの標準により指示
（ｍａｎｄａｔｅ）されず、たとえあるとしてもアプリ
ケーションの少ししか該変化による影響を受けないこと
が期待される。この特徴は、例えばＶｅｒｉｔａｓ、Ｅ
ｐｉｓｏｄｅ、Ｏｕｓｔｅｒｈｏｕｔ及びＭｅｎｄｅｌ
ｂｌｕｍのログ構造化ファイル・システムのような従来
のファイル・システムにおいて実現される。ユーザは、
同期したローカルなディレクトリの更新に任意に戻るこ
とができる。

【００４９】ＭＤＤ初期化ユーティリティｍｅｔａｉｎ
ｉｔ（ｌｍ）は、以下の形式の構成ラインを受け入れる
ため拡張され得る。 ｍｄＮＮ −ｔ ｍａｓｔｅｒ ｌｏｇ ［−ｎ］ ここで、 ｍｄＮＮ メタトランス装置を表すメタデバイスの
名前 ｍａｓｔｅｒ マスター装置；メタデバイス又は通常の
ディスク装置 ｌｏｇ ログ装置；メタデバイス又は通常のディ
スク装置。同じログが多重メタトランス装置において用
いられ得て、その場合その同じログはそれらの多重メタ
トランス装置の間で共用される。

【００５０】メタスタット（ｍｅｔａｓｔａｔ）はま
た、メタトランス装置の状態を表示するため、以下のフ
ォーマットを有して拡張され得る。 mdXX: metatrans device Master device:mdYY Logging device:mdZZ <state information> mdYY: metamirror,master device for mdXX <usual status> mdZZ: mtamirror,logging device for mdXX <usual status> （ ｍｄＸＸ： メタトランス装置 マスター装置：ｍｄＹＹ ロギング装置：ｍｄＺＺ ＜状態情報＞ ｍｄＹＹ： メタミラー、ｍｄＸＸのためのマスター装置 ＜通常の状態＞ ｍｄＺＺ： メタミラー、ｍｄＸＸのためのロギング装置 ＜通常の状態＞ ） ｆｓｃｋは、クリーン・フラグの状態に基づいてシステ
ムをチェックすべきか判断する。本明細書において記載
される本発明の特定のインプリメンテーションは、新し
いクリーン・フラグ値ＦＳＬＯＧを定義する。クリーン
・フラグがＦＳＬＯＧであり且つメタトランス装置３２
が例外状態でないならば、「ｆｓｃｋ−ｍ」は０を持っ
て出て（ｅｘｉｔ）、チェッキングはスキップされる。
さもなければ、クリーン・フラグは、従来の要領で扱わ
れる。ｆｓｃｋは、プロジェクト−プライベイトｉｏｃ
ｔｌリクエストによりメタトランス装置３２の状態をチ
ェックする。ファイル・システムを首尾良く修復して
後、ｆｓｃｋは、メタトランス装置３２を例外状態から
取り出すプロジェクト−プライベイトｉｏｃｔｌリクエ
ストを発行する。

【００５１】クリーン・フラグがＦＳＬＯＧであり且つ
メタトランス装置３２が例外状態にないならば、クォー
タチェックはファイル・システムをスキップする。さも
なければ、クォータチェックは、クォータファイル（ｑ
ｕｏｔａｆｉｌｅ）を従来の要領で再作成する。クォー
タチェックは、メタトランス装置３２の状態をプロジェ
クト−プライベイトｉｏｃｔｌリクエストによりチェッ
クする。首尾良くファイル・システムを修復して後は、
クォータチェックは、メタトランス装置３２の例外状態
をリセットするプロジェクト−プライベイトｉｏｃｔｌ
リクエストを発行する。

【００５２】ｕｆｓ ｍｏｕｎｔプログラムは、遅延さ
れたディレクトリ更新を用いるべきか否かを制御をする
ため１対の新しいオプションを受け入れ得る。ヘッダー・ファイル ＜ｓｙｓ／ｆｓ／ｕｆｓ ｉｎｏｄｅ．ｈ＞ｓｔｒｕｃ
ｔ ｕｆｓｖｆｓは、メタトランス装置を識別するため
ｓｔｒｕｃｔ ｍｅｔａｔｒａｎｓに対するポインター
を含み得る。ｉ ｄｏｆｆがｓｔｒｕｃｔ ｉｎｏｄｅ
に追加される。 ＜ｓｙｓ／ｆｓ／ｕｆｓ ｑｕｏｔａ．ｈ＞ｓｔｒｕｃ
ｔ ｄｑｕｏｔは新しいフィールドｄｑ ｄｏｆｆを有
し得る。 ＜ｓｙｓ／ｆｓ／ｕｆｓ ｆｓ．ｈ＞新しいクリーン・
フラグ値ＦＳＬＯＧがここで定義される。ｆｓ ｓｐａ
ｒｅｃｏｎ［５３］はｆｓ−ｒｅｃｌａｉｍと名前を付
け直される。 ＜ｓｙｓ／ｆｓ／ｕｆｓ ｔｒａｎｓ．ｈ＞ ＜ｓｙｓ／ｍｄ ｔｒａｎｓ．ｈ＞これらは、プロジェ
クト−プライベイト・インターフェース、例えばメタト
ランスｉｏｃｔｉコマンド及びデータ構造を規定する新
しいヘッダー・ファイルである。カーネル・インターフェース ｃｏｍｍｏｎ／ｆｓ／ｕｆｓ／＊．ｃ フラグがローカル及び遠隔のアクセスを区別するためデ
ィレクトリＶＯＰコールに加えれらないならば、ＵＦＳ
へのＶＯＰ及びＶＦＳインターフェースは変化する必要
がない。 ｃｏｍｍｏｎ／ｖｍ／ｐａｇｅ ｌｏｃｋ．ｃ 以下のファンクションは、ページ： ｐａｇｅ ｉｏ
ｌｏｃｋ （）、ｐａｇｅ ｉｏ ｕｎｌｏｃｋ
（）、及びｐａｇｅ ｉｏ ｔｒｙｌｏｃｋ ｕｔｐ
ａｇｅ ｉｏ ａｓｓｅｒｔ（）への条件付きのアクセ
スを可能にする。 ｃｏｍｍｏｎ／ｖｍ／ｖｍ ｐｖｎ．ｃ 以下のファンクションは、先のファンクション：ｐｖｎ
ｉｏ ｄｏｎｅを用いて獲得されるページの解放を可
能にする。 ｃｏｍｍｏｎ／ｏｓ／ｂｉｏ．ｃ 新しいファンクションｔｒｙｇｅｔｂｌｋ（）がｂｉ
ｏ．ｃに追加される。このファンクションは、バッファ
ーが特別の装置及びブロック番号に対して存在するかを
チェックし、直ちに書込みを使用可能にする。これらの
条件が満たされるならば、上記のファンクションはポイ
ンターをバッファー・ヘッダーへ返すか、それらの条件
が満たされないならば該ファクションはヌル（ＮＵＬ
Ｌ）を返す。

【００５３】スレッド−特別データ（ｔｈｒｅａｄ−ｓ
ｐｅｃｉｆｉｃ ｄａｔａ）（「ＴＳＤ」）がテストの
ため利用され得る。ファイル・システム・オペレーショ
ンにおいて各デルタ４３は、該デルタ４３を生じている
スレッドと関連される。

【００５４】ＵＦＳマウントは、ｕｆｓｖｆｓフィール
ドｖｆｓ ｔｒａｎｓの中のｕｆｓ ｔｒａｎｓ ｇｅｔ
（）により戻された値を格納する。ヌル（ＮＵＬＬ）値
は、ファイル・システムがメタトランス装置３２からマ
ウントされないことを意味する。ＵＦＳはこの場合通常
のように機能する。非ヌル（Ｎｏｎ−ＮＵＬＬ）値は、
ファイル・システムがメタトランス装置からマウントさ
れることを意味する。この場合は： ａ） オンディスク・クリーン・フラグがＦＳＬＯＧへ
セットされ、更に、クリーン・フラグ・プロセスがイン
コア（ｉｎ−ｃｏｒｅ）・クリーン・フラグをＦＳＢＡ
Ｄへセットすることによりディスエーブルされる。クリ
ーン・フラグ・プロセスをディスエーブルすることがＣ
ＰＵオーバーヘッドをセーブする。

【００５５】ｂ） 「ｎｏｓｙｎｃｄｉｒ」マウント・
オプションが特定されないならば、ＤＩＯフラグがセッ
トされる。ローカルなディレクトリ更新が遅延された書
込みにより記録される。破壊がこれらのオペレーション
を失うことを可能にする。遠隔のディレクトリ・オペレ
ーションは同期したままである。ディレクトリ・オペレ
ーションは、Ｔ ＤＯＮＴＰＥＮＤがｃｕｒｔｈｒｅａ
ｄ−＞ｔ ｆｌａｇにセットされるとき、遠隔であると
見做される。

【００５６】ｃ） 例外ルーチンがメタトランス装置３
２にマウント時に登録（ｒｅｇｉｓｔｅｒ）される。メ
タトランス・ドライブは、例外条件が発生するときこの
ルーチンを呼出す。例外条件は、装置エラーと、ドライ
バの状態の中の検出された不一致とを含む。ＵＦＳ例外
ルーチンは、影響を及ぼされるファイル・システムをハ
ード・ロック（ｈａｒｄ ｌｏｃｋ）するカーネル・ス
レッドを始める。

【００５７】各ＵＦＳ Ｖｎｏｄｅ又はＶＦＳオペレー
ションは、１つ以上のトランザクションを発生し得る。
トランザクションはネストされ得る。即ち、トランザク
ションは、その中に全体的に含まれるサブトランザクシ
ョンを含み得る。ネストされたトランザクションは、オ
ペレーションが他のオペレーションをトリガーするとき
生じる。典型的には、各ＵＦＳオペレーションは、それ
と関連する１つのトランザクション（プラスいずれかの
ネストされたトランザクション）を有する。しかしなが
ら、単一のトランザクションがロギング装置４６の全体
のサイズを越えるとき、ＶＯＰ ＷＲＩＴＥやＶＦＳ
ＳＹＮＣのような特定のオペレーションが多重のトラン
ザクションに分割される。ＶＯＰ ＣＭＰやＶＯＰ Ａ
ＤＤＭＡＰのような他のものは、それらがファイル・シ
ステム状態を決して変えないので、何のトランザクショ
ンも発生しない。ファイル・システムを直接変えない一
部のオペレーションは、トランザクションを副作用の結
果として発生し得る。例えば、ＶＯＰ ＬＯＯＫＵＰ
は、ｄｎｌｃ又はｉノード・キャッシュにおいてエント
リーを置換し、イン−コア・ｉノードを非活動になら
せ、それらと関連するページがディスクに書込まれるよ
うにし得る。

【００５８】トランザクションは、ＴＲＡＮＳ ＢＥＧ
ＩＮ （）に対するコールにより始まる。トランザクシ
ョンは、ＴＲＡＮＳ ＥＮＤが呼出されると終了する。
トランザクションはデルタ４３から構成され、該デルタ
４３はファイル・システムのメタデータへの更新であ
る。メタデータは、スーパーブロック、サマリー情報、
シリンダー・グループ、ｉノード、割当てブロック及び
ディレクトリーである。ＵＦＳは、ＴＲＡＮＳ ＤＥＬ
ＴＡ （）を呼出すことによりメタトランス装置３２に
対するデルタ４３を識別する。このコールは、ログされ
るべきバッファー内でバイトの領域を識別する。これら
のバイトは、バッファーが書込まれるときログされる。
ＵＦＳは、しばしば同じメタデータを単一のオペレーシ
ョンのため何度も変更する。デルタ４３の宣言をデルタ
４３のロギングから分離すると、多重更新は１つのデル
タ４３へ縮小（ｃｏｌｌａｐｓｅ）する。

【００５９】ＵＦＳは、ユーザ・データのためのディス
ク・ブロック及び割当てブロックを同じフリー・プール
から得る。その結果、ユーザ・データは、ある早期の時
点にメタデータを含んだディスクの場所を占有し得る。
ログ設計は、回復中、ユーザ・データがデルタ４３によ
り前のメタデータへ不正確に更新されないことを保証し
なければならない。ＵＦＳは、ブロックがユーザ・デー
タに対して割り当てられるときは常に、ＴＲＡＮＳ Ｃ
ＡＮＣＥＬ（）を呼出すことにより上記のことを防ぐ。

【００６０】生の（ｒａｗ）又はブロックのメタトラン
ス装置３２への書込みは、ログに記録された情報を無効
にすることができる。不一致を回避するため、ドライバ
はこれらの書込みをトランザクションする。

【００６１】ロギング装置４６は、同期書込みを一緒に
バッチ化（ｂａｔｃｈ）することにより、且つバッチ化
されたデータをロギング装置４６に順に書込むことによ
り同期書込み性能を増大させる。データは、マスター装
置４４に同時に非同期で書込まれる。ログに記録された
同期書込みデータは、トランザクションに組織化（ｏｒ
ｇａｎｉｚｅ）されない。メタトランス装置３２は、フ
ァイル・システム・レベルでの介入なしに同期書込みを
透過的にログする。同期書込みされるユーザ・データ
は、ログの中に十分なフリー・スペースがないときログ
されない。この場合、マスター装置４４への通常の同期
書込みが行われる。

【００６２】同期書込みデータがログされるとき、ディ
スクの同じ場所に対するいずれの早期のログ記録は、回
復中又はロール−フォワード（ｒｏｌｌ−ｆｏｗａｒ
ｄ）中のデータに対して正しくない変更をすることを回
避するため取り消されねばならない。データのマスター
装置４４への非同期書込みが終わると、メタトランス・
ドライバが行ったルーチンは、ログされるべきアイテム
のリスト上に取り消し記録を置く。同じディスク場所へ
の後続の同期書込みに対して、上記の記録をログへフラ
ッシュし先の書込みを取り消す同期コミットが続く。同
じディスク場所への後続の非同期の書込みは、それらに
ｓｙｎｃ （）、ｆｓｙｎｃ （）あるいは更に同期更
新が続かなければ、リブートで消滅する。このスキーム
の正しさは、ＵＦＳがディスク場所への新しい書込みを
開始しないで一方先の書込みが依然進行していることに
依存する。

【００６３】マスター装置４４は、ログの中のコミット
された変化により周期的に更新される。ログのヘッドで
記録された変化は最初ロールされる。３つの実施処置
（ｐｅｒｆｏｒｍａｎｃｅ ｍｅａｓｕｒｅ）がログの
ローリングのオーバーヘッドを低減する。第１に、ドラ
イバは、必要とされたデータがバッファー・キャッシュ
及びページ・キャッシュのいずれかにおいて利用可能で
あるとき、ログの読出しを回避する。２つの新しいルー
チンｔｒｙｇｅｔｂｌｋ（）及びｕｆｓ ｔｒｙｐａｇ
ｅ（）が、スリーピングすることなしにバッファー・ヘ
ッダー又はページを返す。即ちそれらはヌル（ＮＵＬ
Ｌ）を返す。第２に、オーバーラップするデルタ４３が
取り消される。ログが同じデータのための多重更新を含
むならば、必要とされる最小の組のみがログから読出さ
れ与えられる。第３の処置は、トランザクションされな
い同期書込みデータを関連させる。このデータは、ロギ
ング装置４６へ同期書込みされ、マスター装置４４へ非
同期で書込まれる。ロール論理は単純に非同期書込みが
完了するのを待つ。

【００６４】ローリングは、メタトランス・ドライバに
より開始される。ロギング装置４６が一杯になると、メ
タトランス・ドライバはログをカレント・スレッドのコ
ンテキストにおいて直ちにロールする。さもなければ、
メタトランス・ドライバは、ローリングが効率的であり
且つそれがカーネル・スレッドを開始する時をヒューリ
スティックに（ｈｅｕｒｉｓｔｉｃａｌｌｙ）決定す
る。この場合に対する明らかなヒューリスティック（ｈ
ｅｕｒｉｓｔｉｃ）は、メタトランス・ドライバが数秒
間アイドル状態にある時である。ログは、ｆｓｙｎ
ｃ（）、ｓｙｎｃ（）あるいはマウント解除で前方へロ
ールされず、メタトランス装置３２がｍｅｔａｃｌｅａ
ｒ（ｌｍ）ユーティリティによりクリアされるときロー
ルされる。

【００６５】メタトランス装置３２は、データの損失を
生じ得るエラーが発生する場合それ自身例外状態に置
く。この状態において、メタトランス装置３２は、装置
に対する登録された全部の「コールバック−オン−エク
セプション（ｃａｌｌｂａｃｋ−ｏｎ−ｅｘｃｅｐｔｉ
ｏｎ）（例外時コールバック）」ルーチンを呼出して後
に、各読出し又は書込みの際にＥＩＯを戻す。

【００６６】ＵＦＳは、コールバック用ルーチンをマウ
ント時に登録する。ＵＦＳルーチンは、影響を受けたＵ
ＦＳファイル・システムをハード・ロックするカーネル
・スレッドを開始させ、手動の回復を可能にする。通常
の手順は、ファイル・システムをマウント解除し、エラ
ーを固定し、ｆｓｃｋをランすることである。ｆｓｃｋ
は、それがファイル・システムを修復して後に、装置を
例外状態から取り出す。次いで、ファイル・システムは
マウントされ得て、ファイル・システムは正常の通り機
能する。ファイル・システムが、マウント解除され、次
いでｆｓｃｋをランすることなく再びマウントされるな
らば、装置へのいずれの書込みはＥＩＯを戻すが、必要
とされるデータがアクセスされ得るならば、読出しは進
行する。

【００６７】ＵＦＳはログ・スペースを使い尽くす必要
はなく、もしメタトランス・ドライバが不十分なログ・
スペースのためトランザクションをコミットすることが
できないならば、メタトランス・ドライバはその条件を
致命的な例外として扱う。ＵＦＳは、特定のオペレーシ
ョンを必要なとき多重トランザクションに分割すること
により上記の状況を回避する。ＵＦＳフラッシュ・ルー
チンは、全てのｕｆｓ ｓｙｎｃｉｐ （）又はＶＯＰ
ＰＵＴＰａｇｅコールに対してのトランザクションを生
成する。フラッシュ・ルーチンは、ｕｆｓ ｆｌｕｓｈ
ｉ（）、ｕｆｓ ｉｆｌｕｓｈ （）及びｕｆｓ ｆｌ
ｕｓｈ ｉｃａｃｈｅ （）である。影響を受けたＵＦ
Ｓオペレーションは、ＶＦＳ Ｓｙｎｃと、ＶＦＳ Ｕ
ＮＭＯＵＮＴと、ＵＦＳ ｉｏｃｔｌｓ ＦＩＯＬＦ
Ｓ、ＦＩＯＦＦＳ及びＦＩＯＤＩＯとである。ＶＯＰ
ＷＲＩＴＥオペレーションは、ｕｆｓ ｗｒｉｔｅ
（）における多重ｒｗｉｐ （）コールに分割され
る。

【００６８】ファイルをｕｆｓ ｉｉｎａｃｔｉｖｅ
（）においてフリーにすることは、トランザクションの
衝突と再帰的なＵＦＳオペレーションとを伴うデッドロ
ック問題のため多重トランザクションに分割されること
ができなく、そしてファイルをフリーにすることが、デ
ッドロックの機会が存在しなくなるまで遅らされる。

【００６９】メタトランス・ドライバは、ブートにおい
てオープンしていて削除されるファイルにより保持され
る資源を回復しない。代わりに、ＵＦＳはこの問題を管
理する。マウント時に生成されたカーネル・スレッド
が、以下の場合に削除されたファイルに対して走査す
る。該以下の場合とは ａ） ファイル・システムがメタトランス装置３２にあ
るか、又は ｂ） スーパーブロックが、削除されるファイルがある
と言う。スーパーブロックにおける先に用いられていな
いスペアにおけるビットがいずれかのかかるファイルが
存在するかを指示する。

【００７０】メタトランス装置３２ドライバは、３つの
クラスのエラー、即ち「装置エラー」、「データベース
・エラー」及び「内部エラー」を扱う。装置エラーは、
ロギング装置４６又はマスター装置４４の読出しあるい
は書込みにおけるエラーである。データベース・エラー
は、ＭＤＤのデータベース・ルーチンにより報告される
エラーである。内部エラーは、ロギング装置４６上へ書
込まれるストラクチャを含む内部ストラクチャにおいて
検出される不一致である。

【００７１】マウントされたメタトランス装置３２は、
エラーに対して２つの方法の一つで応答する。メタトラ
ンス・ドライバは、いずれの他の作用なしでコーラー
（ｃａｌｌｅｒ）までデータの完全性との妥協をしない
エラーを通す。例えば、この種のエラーは、ログされな
いデータをマスター装置４４から読出している間に生じ
得る。エラーが、失われた又は破壊されたデータ、例え
ばロギング装置４６の誤り読出し又は書込み、あるいは
ＭＤＤのデータベース・ルーチンからのエラーをもたら
し得るときは常に、メタトランス装置３２は、それ自身
を例外状態に置く。メタトランス装置３２は、それ自身
を例外状態に以下の状況により置く。該以下の状況とは
次の通りである。

【００７２】ａ） 可能なとき例外をＭＤＤのデータベ
ースに記録する。

【００７３】ｂ） いずれの登録された「コールバック
−オン−エクセプション」ルーチンを呼出す。これらの
ルーチンはマウント時に装置により登録される。ＵＦＳ
は、影響を受けたＵＦＳファイル・システムをハード・
ロックするカーネル・スレッドを開始するルーチンを登
録する。これらのファイル・システムは、マウント解除
され得て、次いで例外条件が訂正された後に再マウント
（ｒｅｍｏｕｎｔ）され得る。

【００７４】ｃ） 各読出し又は書込みコールに対して
ＥＩＯを戻す一方、メタトランス装置３２がマウントさ
れる。

【００７５】メタトランス装置３２がマウント解除時に
ｕｆｓ ｔｒａｎｓ ｐｕｔ （）でもってＵＦＳによ
り解放された後に、読出しは、必要とされるデータがア
クセスされ得ないときＥＩＯを戻し、書込みは、常にＥ
ＩＯを戻す。この振る舞いは、メタトランス装置３２が
再びマウントされた後でさえ継続する。

【００７６】ｆｓｃｋがファイル・システムを修復する
とき、ｆｓｃｋはメタトランス装置３２をその例外状態
から取り出す。ｆｓｃｋは、ログを第１のエラーまでロ
ールし該ログの残余を棄て且つ装置を書込み可能にする
プロジェクト−プライベイトｉｏｃｔｌを最初に発行す
る。ファイル・システムを修復した後に、ｆｓｃｋは、
装置をその例外状態から取り出すプロジェクト−プライ
ベイトｉｏｃｔｌを発行する。ブート時に、ロギング装
置４６が走査され、メタトランス装置３２の内部状態が
再構築される。走査中の装置エラーは、メタトランス装
置３２を例外状態に置く。該走査は可能ならば継続す
る。中断（ｉｎｔｅｒｒｕｐｔ）された書込みから生じ
る読出し不能のセクターは、それを書き直すことにより
修復される。メタトランス装置３２は、例外状態に置か
れない。

【００７７】ロール・フォワード・オペレーションは、
ロギング装置４６を走査し内部状態を再構築する間に起
こり得る。ロール・フォワード・オペレーションは、マ
ップ・メモリーがそのリコメンドされた割当てを越え得
るので起こる。これらのロール・フォワード・オペレー
ション中のエラーは、メタトランス装置３２を例外状態
に置き、走査は可能ならば継続する。

【００７８】ローカルなディレクトリ更新の遅延された
記録は性能を改善することができることが分かる。ロー
カルと遠隔の（ＮＦＳ）ディレクトリ・オペレーション
の双方を区別する２つの機構が実施され得る。即ち、 ａ） ＵＦＳは、ｐｒｏｃストラクチャのｐ ａｓメン
バーを検査することができる。（もしそれがヌルならば
コーラーはシステム・プロセス、多分ＮＦＳである。さ
もなければ、オペレーションは、ユーザ−レベル・プロ
セスにより開始されてしまいローカルであるとされる。

【００７９】又は、 ｂ） ＵＦＳは、オペレーションが同期しなければなら
ないか否かを指定するディレクトリのため、新しいフラ
グをＶｎｏｄｅオペレーションに加えることができる
（又は新しいフラグをスレッド構造へ加えることができ
る）。

【００８０】オープンしているが削除されるファイルと
関連する資源は、システムの破壊の後再利用されねばな
らなく、そして本発明はこの目的のためスレッドを含
む。しかしながら、かかるファイルに対してファイル・
システム全体を常に探索するスレッドは、２つの不利、
即ち、探索のオーバーヘッドと、スペースが見つけられ
且つ回復されるまでの有り得る顕著な遅延とを有する。
代替は、スーパーブロックにおけるスペア・フィールド
を用いてかかるファイルの無いケースを最適化すること
であり、そのケースはかなり共通に発生しそうである。

【００８１】ＦＩＯＳＤＩＯ ｉｏｃｔｌは、ＵＦＳフ
ァイル・システムを遅延されたＩＯモードに置く。該遅
延されたＩＯモードは、ローカルなディレクトリ更新が
ディスクへ遅延された書込みにより書込まれることを意
味する。遠隔ディレクトリ更新は、ＮＦＳプロトコルに
より要求されるように、同期したままである。このモー
ドは、ディレクトリ・オペレーションを非常に早くする
が、しかし本発明なしではそれは安全でなく、ＤＩＯモ
ードにおけるファイル・システムの修復はユーザの介入
を通常必要とする。本発明のロギング機構はその危険を
改善する。ディレクトリ更新性能を改善するため、ファ
イル・システムは、「ｎｏｓｙｎｃｄｉｒ」マウント・
オプションが指定されないならば、遅延されたＩＯモー
ドに置かれ得る。しかしながら、遅延されたＩＯモード
の実施は、相当に変化し、解法は、ＦＩＯＳＤＩＯフラ
グの使用を回避し、その代わりに異なる特別のフラグを
使用することである。この特別のフラグは、新しいユー
ティリティ及びプロジェクト−プライベイトＵＦＳ ｉ
ｏｃｔｌにより管理される。新しいフラグは、スーパー
ブロックに格納され得て、又はＭＤＤのデータベースに
格納され得る。次いで、ＦＩＯＳＤＩＯ ｉｏｃｔｌ
は、本発明によりファイル・システムに何の影響を及ぼ
さない。メタトランス装置に対するＵＦＳインターフェース メタトランス装置３２が生成されるとき又はブートで再
び生成されるとき、メタトランス装置３２は、それ自身
をＵＦＳにより記録する。

【００８２】

【表１】 ｄｅｖはメタトランス装置の番号である。ｄａｔａはメ
タトランス−プライベイト・ストラクチャのアドレスで
ある。ｏｐｓは分岐テーブルのアドレスである。

【００８３】

【表２】 ｕｆｓ ｔｒａｎｓ ｓｅｔは、上記の情報を以下のも
のの単独にリンクされたリストに格納する。

【００８４】

【表３】 ｕｆｓ ｔｒａｎｓ ｒｅｓｅｔ（）は、ｕｆｓｔｒａ
ｎｓストラクチャをリンク解除しフリーにする。ｕｆｓ
ｔｒａｎｓ ｒｅｓｅｔ （）は、メタトランス装置
がクリアされたとき呼出される。

【００８５】マウント時に、ＵＦＳは、ｕｆｓｔｒａｎ
ｓストラクチャのアドレスをｓｔｒｕｃｔ ｕｆｓｖｆ
ｓのｖｆｓ ｔｒａｎｓフィールドに格納する。

【００８６】

【表４】 ｕｆｓ ｔｒａｎｓ ｇｅｔは、ファイル・システムが
メタトランス装置３２にないときヌル（ＮＵＬＬ）を返
すならば、ｕｆｓ ｔｒａｎｓ ｏｎｅｒｒｏｒは、致
命的な装置エラーが生じるときメタトランス装置３２に
より呼出される。ｕｆｓ ｔｒａｎｓ ｏｎｅｒｒｏｒ
ｓｔａｔｅは、メタトランス装置３２のエラー状態の
一部として格納される。このエラー状態は、ｆｓｃｋ及
びクォータチェックにより問い合わされてリセットされ
る。

【００８７】ＵＦＳは、メタトランス装置をｕｆｓｔｒ
ａｎｓｏｐｓテーブルを介して呼出す。これらのコール
は、以下の複数のマクロ（ｍａｃｒｏ）の内側に埋め
（ｂｕｒｙ）られる。

【００８８】

【表５】

【表６】

【表７】 ｕｆｓｖｆｓストラクト内のｖｆｓ ｔｒａｎｓフィー
ルドの外に、新しいフィールドｏｆｆ ｔ ｉ ｄｏｆ
ｆが＊ｉｎｃｏｒｅ＊ｉｎｏｄｅ，ｓｔｒｕｃｔ ｉｎ
ｏｄｅに加えられる。ｉ ｄｏｆｆは、ｕｆｓ ｉｇｅ
ｔ（）にセットされる。ｉ ｄｏｆｆは、ｉノードのｄ
ｉｎｏｄｅに対する装置オフセットである。ｉ ｄｏｆ
ｆは、ＴＲＡＮＳ ＩＮＯＤＥ（）マクロ及びＴＲＡＮ
Ｓ ＩＮＯＤＥ ＩＴＥＭ（）マクロに対するコードの
量を低減する。同様に、フィールドｄｑ ｄｏｆｆが、
「ｉｎｏｃｒｅ」クォータ・ストラクチャｓｔｒｕｃｔ
ｄｑｕｏｔに加えられる。

【００８９】ｆｓ Ａについてのオペレーションがｆｓ
Ｂについてのトランザクションを生じさせるならばシ
ステムはデッドロックするので、ｕｆｓ ｉｉｎａｃｔ
ｉｖｅ（）とｕｆｓ ｉｇｅｔ（）の間のプロトコルは
変えられる。このことは、ｕｆｓ ｉｉｎａｃｔｉｖｅ
がｉノードをフリーにするとき、又はｕｆｓ ｉｉｎａ
ｃｔｉｖｅがｕｆｓ ｓｙｎｃｉｐ（）を呼出すとき、
ｕｆｓ ｉｉｎａｃｔｉｖｅにおいて起こる。上記のこ
とは、ｕｆｓ ｉｇｅｔ（）がｉノード上のｕｆｓ ｓ
ｙｎｃｉｐ（）をフリー・リストから呼出すときｕｆｓ
ｉｇｅｔ（）において起こる。本発明の実施におい
て、スレッドは、アイドルｉノードをクリーンして、そ
のアイドルｉノードをアイドル待ち行列（ｑｕｅｕｅ）
から新しい「真にフリーの（ｒｅａｌｌｙ−ｆｒｅ
ｅ）」リストへ移動させる。「真にフリーの」リスト上
のｉノードは、真にフリーであり、何の状態も含まな
い。実際に、それらは、ｉノードに対してたまたま適正
サイズであるメモリーの単なる部分である。ｕｆｓ ｉ
ｇｅｔ（）は、上記のリストのｉノード、又はｋｍｅｍ
ａｌｌｏｃ（）の新しいｉノードを用いる。

【００９０】スレッドは、待ち行列上のｉノードの数が
ｕｆｓ ｎｉｎｏｄｅの２５％を越えるときランする。
ｕｆｓ ｎｉｎｏｄｅ Ａは、ｉノード・キャッシュに
おけるｉノードのユーザが示唆した最大数である。ｕｆ
ｓ ｎｉｎｏｄｅはｉノード・キャッシュのサイズを制
限しないことに注目すべきである。アクティブなｉノー
ドの数と、ページを伴ったアイドルｉノードの数とは、
結合されていないままで有り得る。スレッドは、ｉノー
ドの待ち行列の長さがｕｆｓ ｎｉｎｏｄｅの１２．５
％より小さくなるまでｉノードをクリーンする。

【００９１】幾つかの新しいカウンターが、ｉｎｏｄｅ
ｓｔａｔｓストラクチャへ加えられ得る。

【００９２】

【表８】 ｕｆｓ ｉｉｎａｃｔｉｖｅは、削除されるファイルに
より保持されたオンディスク資源をフリーにする。ｉノ
ードをｕｆｓ ｉｉｎａｃｔｉｖｅ（）においてフリー
にすることは、システムを上述のようにデッドロックさ
せることができ、同じ解法を用い得る。即ち、削除され
るファイルがスレッドにより処理される。スレッドの待
ち行列はｕｆｓ ｎｉｎｏｄｅエントリーに制限され
る。ｕｆｓ ｒｍｄｉｒ（）とｕｆｓ ｒｅｍｏｖｅ（）
とは該制限を実施（ｅｎｆｏｒｃｅ）する。

【００９３】トランザクションをエンターしながらｉノ
ード・キャッシュのロックが中止されるときスレッドが
該ｉノード・キャッシュのロックを保持するならば、シ
ステムはデッドロックする。その時点で十分なログ・ス
ペースがないならば、スレッドはトランザクションをエ
ンターすることを中止する。ｉノード走査ファンクショ
ンｕｆｓ ｆｌｕｓｈｉ、ｕｆｓ ｉｆｌｕｓｈ及びｕ
ｆｓ ｆｌｕｓｈ ｉｎｏｄｅｓは、ｉノード・キャッ
シュ・ロックを保持しない単一の走査−ｉノード−ハッ
シュ（ｈａｓｈ）ファクションを用いる。

【００９４】

【表９】

【表１０】 ｕｆｓ ｉｇｅｔは同じプロトコルを用いる。新しいｉ
ｇｅｔ／ｉｉｎａｃｔｉｖｅプロトコルがキャッシュさ
れたｉノードを再使用しようとする固有の問題を未然に
防ぐので、上記のプロトコルは可能である。

【００９５】ｌｏｃｋｆｓフラッシュ・ルーチンｕｆｓ
ｆｌｕｓｈ ｉｎｏｄｅｓは、本発明を実施するため
変更される。ｕｆｓ ｆｌｕｓｈ−ｉｎｏｄｅｓは、ｉ
ノードをフラッシュしながらそれらを隠す。ｉノードを
ｉノード・キャッシュから取り出しそれらをフラッシュ
し次いでそれらをキャッシュに戻して置くことにより、
該ｉノードは隠される。しかしながら、隠されたｉノー
ドをトランザクションの終わりで見つけることができな
い。ｕｆｓ ｆｌｕｓｈ ｉｎｏｄｅは、ここで新しい
ｉノード・ハッシュ走査ファクションを用いてｉノード
をフラッシュする。

【００９６】ｕｆｓ ｕｎｍｏｕｎｔ（）は、ｌｏｃｋ
ｆｓプロトコルと新しいｉノード走査ファクションとを
用いるため修正される。ｕｆｓ−ｕｎｍｏｕｎｔはまた
ＵＦＳスレッドを管理する。スレッドの全部が、ｕｆｓ
ｔｈｒｅａｄ．ｃにおけるルーチンの共通の組により
生成され、制御され、且つ破壊される。各スレッドは、
以下のストラクチャにより表される。

【００９７】

【表１１】 以下の疑似コード・リスティングを更に参照すると、コ
ンピュータ・マス・ストレージ装置に対する書込み操作
のアトミシティをシステム障害の事象において保証する
ためのジャーナリング・ファイル・システム用トランザ
クション装置ドライバが更に理解され得る。ファイル・システム・オペレーション

【表１２】 特定のコンピュータ・オペレーティング・システムと関
連して本発明の原理が上記において記述されたが、上記
の記述は例示によってのみで本発明の範囲の制限として
なされたものではない。

【図面の簡単な説明】

【図１】本発明のオペレーション環境の一部を形成する
汎用コンピュータの単純化して表した図である。

【図２】本発明の代表的な実施を行うためコンピュータ
・プログラムの選択された要素がコンピュータ・オペレ
ーティング・システムの種々の層及びインターフェース
と相互作用する要領のアーキテクチャーの全体像を提供
する単純化して表した図である。

【図３】上記された例示の実施形態に従った、メタトラ
ンス装置の構成要素と、Ｓｙｓｔｅｍ Ｖベースのコン
ピュータ・オペレーティング・システムのＶｏｐ又はＶ
ＦＳインターフェースを介するその相互作用とを詳細に
示す図２のコンピュータ・プログラムの主要機能構成要
素をより詳細に表した図である。

【図４】メタトランス装置のためのユニット構造がロギ
ング装置ユニット構造のアドレスを含み、またその逆で
あることを示す単純化した論理的ブロック図である。

【図５】ロギング装置のユニット構造がｕ１ ｌｉｓｔ
によりアンカーされるグローバルなリンクされたリスト
について維持され、ロギング装置を共用するメタトラン
ス装置のための各メタトランス・ユニット構造がロギン
グ装置のユニット構造によりアンカーされるリンクされ
たリストについて維持されることを示す追加の単純化し
た論理的ブロック図である。

【図６】ログマップがマスター装置へロールされること
を必要とするログの中の各デルタに対するｍａｐｅｎｔ
ｒｙ ｔを含み、マップ・エントリーが（メタトランス
ｄｅｖ、メタトランス装置オフセット）によりハッシュ
され且つそれらがロールされるべき順序でリンクされた
リストに維持されることを示す更に単純化した論理的ブ
ロック図である。

【図７】メタトランス装置及びロギング装置のためのユ
ニット構造がログマップのためのアドレスを含むことを
示す単純化した論理的ブロック図である。

【図８】デルタマップが、各メタトランス装置と関連さ
れ、ファイル・システム・オペレーションを備える変化
についての情報を格納し、それと共にメタトランス装置
がデルタマップに格納されている各デルタに対するマッ
プエントリーを生成することを示す追加の単純化した論
理的ブロック図である。

【図９】トランザクションの終わりで、各マップ・エン
トリーにより記録されたコールバックが呼ばれ、ログマ
ップ層がデルタ・プラス・データをログの書込みバッフ
ァーに格納し、マップ・エントリーをログマップの中へ
置くことを示す更に単純化した論理的ブロック図であ
る。

【図１０】ログマップがまた読出し操作のため用いられ
ること、また読出されているバッファーがログマップに
おいていずれのエントリーもオーバーラップしないなら
ば、読出し操作が下方のマスター装置へ通され、さもな
ければ、バッファーに対するデータがマスター装置から
のデータとロギング装置からのデータの組み合わせであ
ることを示す単純化した論理的ブロック図である。

【図１１】ブート・プロセスにおける早期に、各メタト
ランス装置は、それ自身をＵＦＳファンクションｕｆｓ
ｔｒａｎｓ ｓｅｔにより記録し、ｕｆｓｔｒａｎｓ
ストラクトを生成し、それをグローバルなリンクされた
リスト上にリンクすることを示す図である。

【図１２】マウント時で、ファイル・システムがそのｄ
ｅｖ ｔを、ｕｆｓｔｒａｎｓストラクトに格納された
他のｄｅｖ ｔ（複数）に対してチェックし、整合があ
る場合はファイル・システムはｕｆｓｔｒａｎｓストラ
クトのアドレスをそのファイル・システムの特別のパー
マウント・ストラクト（ｕｆｓｖｆｓ）に格納し、それ
と共にその総称的なパーマウント・ストラクト（ｖｆ
ｓ）をｕｆｓｔｒａｎｓストラクトに格納することを更
に示す図である。

【図１３】始めオペレーション、終わりオペレーション
及びデルタ記録機能を含む、ｕｆｓｔｒａｎｓｏｐｓス
トラクトにおけるエントリー・ポイントを呼び出すこと
によりファイル・システムがドライバと通信することを
示す前の図面に示されるオペレーティング・システム・
カーネルとメタトランス・ドライバとの間のインターフ
ェースの追加の図である。

【符号の説明】

１ プロセッサ ５ キーボード ６ ディスプレイ・ユニット ７ ＣＤＲＯＭユニット ８ ＣＤＲＯＭ媒体 ９ ディスク記憶ユニット １０ プログラム ２０ アーキテクチャ ２２ ユーザ（又はシステム・コール）層 ２４ カーネル ２６ メタトランス層 ３０ ＵＦＳ層 ３２ メタトランス装置 ４１ バッファー又はページ・キャッシュ ４２ ＶＯＰ又はＶＦＳインターフェース ４３ デルタ ４５ トランスオプス・インターフェース ５８ バッファー又はページ・ドライバ

Claims (14)

【特許請求の範囲】
1. 【請求項１】 ジャーナリング・ファイル・システムを
   有するコンピュータ・オペレーティング・システムと関
   連したコンピュータ・マス・ストレージ装置へ書込まれ
   るデータのアトミシティを保証するための方法におい
   て、 ファイル・システム・オペレーションの始まりをトラン
   ザクション装置へ指示するステップと、 少なくとも１つのファイル・システム・オペレーション
   を実行するステップと、 前記少なくとも１つのファイル・システム・オペレーシ
   ョンに応答してファイル・システム・データを変えるス
   テップと、 前記の変えられたファイル・システム・データの選択さ
   れた特性を前記トランザクション装置に知らせるステッ
   プと、 前記ファイル・システム・オペレーションの終わりを前
   記トランザクション装置へ宣言するステップと、 前記ファイル・システム・オペレーションと関連した前
   記の変えられたファイル・システム・データを、前記ト
   ランザクション装置と関連するログへコミットするステ
   ップと、 前記の変えられたファイル・システム・データを前記ロ
   グから前記コンピュータ・マス・ストレージ装置へ書込
   むステップとを備える方法。
2. 【請求項２】 前記指示するステップが、識別番号を前
   記ファイル・システム・オペレーションへ割り当てるこ
   とにより実行される請求項１記載の方法。
3. 【請求項３】 前記実行するステップ及び前記変えるス
   テップが、複数のファイル・システム・オペレーション
   のため繰り返し実行される請求項１記載の方法。
4. 【請求項４】 前記知らせるステップが、前記の変えら
   れたファイル・システム・データのオフセット及びサイ
   ズを決定することにより実行される請求項１記載の方
   法。
5. 【請求項５】 前記の変えられたファイル・システム・
   データを分析して前記ファイル・システムに対する該デ
   ータの相対的重要性を決定するステップと、前記の変え
   られたファイル・システム・データが前記ファイル・シ
   ステムに対して相対的に重要でない場合前記の変えられ
   たファイル・システム・データを前記コンピュータ・マ
   ス・ストレージ装置へ直接書込むステップとを更に備え
   る請求項１記載の方法。
6. 【請求項６】 データを前記コンピュータ・マス・スト
   レージ装置から読出すステップと、 前記の読出されたデータを前記ログと関連するバッファ
   ーへ書込むステップと、 前記ログが前記の読出されたデータに対する更新を含む
   かを決定するステップと、 前記ログが前記の読出されたデータに対する更新を含む
   場合前記バッファーの中の前記の読出されたデータを更
   新するステップとを更に備える請求項１記載の方法。
7. 【請求項７】 コンピュータが使用できる媒体を備える
   コンピュータ・プログラム製品であって、前記コンピュ
   ータが使用できる媒体は、ジャーナリング・ファイル・
   システムを有するコンピュータ・オペレーティング・シ
   ステムのファイル・システム・オペレーションに応答し
   てコンピュータ・マス・ストレージ装置へ書込まれるデ
   ータのアトミシティを保証するため前記媒体の中に包含
   されたコンピュータ可読コードを有する、コンピュータ
   ・プログラム製品において、 コンピュータがファイル・システム・オペレーションの
   始まりをトランザクション装置へ指示するよう構成され
   たコンピュータ可読プログラム・コード装置と、 コンピュータが少なくとも１つのファイル・システム・
   オペレーションを実行するよう構成されたコンピュータ
   可読プログラム・コード装置と、 コンピュータが前記少なくとも１つのファイル・システ
   ム・オペレーションに応答してファイル・システム・デ
   ータを変えるよう構成されたコンピュータ可読プログラ
   ム・コード装置と、 コンピュータが前記の変えられたファイル・システム・
   データの選択された特性を前記トランザクション装置へ
   知らせるよう構成されたコンピュータ可読プログラム・
   コード装置と、 コンピュータが前記ファイル・システム・オペレーショ
   ンの終わりを前記トランザクション装置に対して宣言す
   るよう構成されたコンピュータ可読プログラム・コード
   装置と、 コンピュータが前記ファイル・システム・オペレーショ
   ンと関連した前記の変えられたファイル・システム・デ
   ータを前記トランザクション装置と関連するログへコミ
   ットさせるよう構成されたコンピュータ可読プログラム
   ・コード装置と、 コンピュータが前記の変えられたファイル・システム・
   データを前記ログから前記コンピュータ・マス・ストレ
   ージ装置へ書込むよう構成されたコンピュータ可読プロ
   グラム・コード装置とを備えるコンピュータ・プログラ
   ム製品。
8. 【請求項８】 コンピュータがファイル・システム・オ
   ペレーションの始まりをトランザクション装置へ指示す
   るよう構成された前記コンピュータ可読プログラム・コ
   ード装置が、コンピュータが識別番号を前記ファイル・
   システム・オペレーションへ割り当てるよう構成された
   コンピュータ可読プログラム・コード装置により実行さ
   れる請求項７記載のコンピュータ・プログラム製品。
9. 【請求項９】 コンピュータが少なくとも１つのファイ
   ル・システム・オペレーションを実行するよう構成され
   た前記コンピュータ可読プログラム・コード装置と、コ
   ンピュータが前記少なくとも１つのファイル・システム
   ・オペレーションに応答してファイル・システム・デー
   タを変えるよう構成された前記コンピュータ可読プログ
   ラム・コード装置とが、コンピュータが複数のファイル
   ・システム・オペレーションのため少なくとも１つのフ
   ァイル・システム・オペレーションを実行し且つ前記少
   なくとも１つのファイル・システム・オペレーションに
   応答してファイル・システム・データを変えることを繰
   り返し行うよう構成されたコンピュータ可読プログラム
   ・コード装置により実行される請求項７記載のコンピュ
   ータ・プログラム製品。
10. 【請求項１０】 コンピュータが前記の変えられたファ
    イル・システム・データの選択された特性を前記トラン
    ザクション装置へ知らせるよう構成された前記コンピュ
    ータ可読プログラム・コード装置が、コンピュータが前
    記の変えられたファイル・システム・データのオフセッ
    ト及びサイズを決定するよう構成されたコンピュータ可
    読プログラム・コード装置により実行される請求項７記
    載のコンピュータ・プログラム製品。
11. 【請求項１１】 コンピュータが前記の変えられたファ
    イル・システム・データを分析して前記ファイル・シス
    テムに対する当該データの相対的重要性を決定するよう
    構成されたコンピュータ可読プログラム・コード装置
    と、 コンピュータが前記の変えられたファイル・システム・
    データが前記ファイル・システムに対して相対的に重要
    でない場合前記の変えられたファイル・システム・デー
    タを前記コンピュータ・マス・ストレージ装置へ直接書
    込むよう構成されたコンピュータ可読プログラム・コー
    ド装置とを更に備える請求項７記載のコンピュータ・プ
    ログラム製品。
12. 【請求項１２】 コンピュータがデータを前記コンピュ
    ータ・マス・ストレージ装置から読出すよう構成された
    コンピュータ可読プログラム・コード装置と、 コンピュータが前記の読出されたデータを前記ログと関
    連するバッファーへ書込むよう構成されたコンピュータ
    可読プログラム・コード装置と、 コンピュータが前記ログが前記の読出されたデータに対
    する更新を含むかを決定するよう構成されたコンピュー
    タ可読プログラム・コード装置と、 コンピュータが前記ログが前記の読出されたデータに対
    する更新を含む場合前記バッファーの中の前記の読出さ
    れたデータを更新するよう構成されたコンピュータ可読
    プログラム・コード装置とを更に備える請求項７記載の
    コンピュータ・プログラム製品。
13. 【請求項１３】 アプリケーション・プログラムをラン
    するためコンピュータにロード可能なコンピュータ・オ
    ペレーティング・システムと、前記コンピュータと関連
    したコンピュータ・マス・ストレージ装置であって前記
    オペレーティング・システムのジャーナリング・ファイ
    ル・システムに応答してデータを受け取るコンピュータ
    ・マス・ストレージ装置とを含むコンピュータにおい
    て、 前記オペレーティング・システムが、ログ装置とそれと
    関連するバッファーとを含むメタトランス装置を備え、 当該メタトランス装置が、前記オペレーティング・シス
    テム層のファイル・システム層を前記コンピュータ・マ
    ス・ストレージ装置のドライバに結合させ、 記録を前記ログに作成するための前記メタトランス装置
    は、前記ファイル・システムの層から受け取る更新され
    たトランザクション・データを含み、 前記メタトランス装置は、前記更新されたトランザクシ
    ョン・データが前記バッファーにある場合前記更新され
    たトランザクション・データを前記コンピュータ・マス
    ・ストレージ装置に書込む、コンピュータ。
14. 【請求項１４】 前記ログ装置と関連したデルタ・マッ
    プと、その関連のバッファーであって前記メタトランス
    装置のバッファーとを更に備え、 前記メタトランス装置は、 オリジナル・データを前記コンピュータ・マス・ストレ
    ージ装置から読出し、 前記オリジナル・データと前記デルタ・マップからの前
    記トランザクション・データとを区別して、更新された
    データを前記コンピュータ・マス・ストレージ装置へ戻
    して書込む前に前記バッファーの中の前記トランザクシ
    ョン・データを更新する請求項１３記載のコンピュー
    タ。