JP2007012060A

JP2007012060A - 逆階層構造を有するファイルシステム

Info

Publication number: JP2007012060A
Application number: JP2006174548A
Authority: JP
Inventors: Dan Dodge; ドッジダン
Original assignee: QNX Software Systems GmbH
Current assignee: QNX Software Systems GmbH
Priority date: 2005-07-01
Filing date: 2006-06-23
Publication date: 2007-01-18
Also published as: CN1983265A; EP1739575A2; EP1739575B1; CA2550871C; US20070005615A1; KR20070003577A; EP1739575A3; CA2550871A1; US8959125B2

Abstract

【課題】従来のファイルシステム階層を改良するコンピュータシステムを提供する。
【解決手段】コンピュータシステム（１０）内のファイルシステムソフトウェア（４７）は、固定データ記憶装置（３０）のファイルを、メタファイル（１２０）に含まれる複数のレコードへと組織するように動作し得る。メタファイル（１２０）内において、ファイルシステムのファイルおよびディレクトリは、逆階層構造において組織され得る。逆階層構造において、子ファイルに対応するレコードおよび親ディレクトリの子ディレクトリは、その親ディレクトリに対応するメタファイルにおけるレコードを直接示す。ファイルシステムの一インプリメンテーションにおいて、メタファイル（１２０）の個々のレコードは、ファイル識別子によってそれぞれアドレス可能であり得る。個々のレコードは、その親ディレクトリレコードのファイル識別子に対応する親識別子を含み得る。
【選択図】図１

Description

本発明は一般に、コンピュータ、埋め込み型コントローラなどにおける使用のためのファイルシステムに関する。より詳細には、本発明は、逆階層構造を有するファイルシステムに関する。

コンピュータ、内蔵コントローラ、および他のマイクロプロセッサベースのシステムは、通常、様々な異なるハードウェアの構成要素から構成される。ハードウェア構成要素は、プロセッサ、Ｉ／Ｏデバイス、ヒューマンインターフェースデバイスなどを含み得る。付け加えて、そのようなシステムは、システムにおいて使用されるデータを維持するための、メモリ格納ユニットを使用する。メモリ格納ユニットは、ハードディスクドライブ、フロッピー（登録商標）ディスクドライブ、ランダムアクセスメモリ、フラッシュメモリなどを含む、様々な異なる形態を取り得るが、それらに限定されるわけではない。

そのようなシステムにおいて実行されるハイレベルのアプリケーションプログラムは、しばしば、メモリ記憶装置ユニットを含むこれらのハードウェア構成要素とシームレスに遣り取りをしなければならない。この目的に対して、多くのシステムは、アプリケーションプログラムとシステムハードウェアとの間におけるインターフェースとしての機能を果たすオペレーティングシステムを実行する。ファイルシステムソフトウェアはオペレーティングシステムの一部として含まれ得るか、または、オペレーティングシステムと遣り取りをする補助的なソフトウェア構成要素として提供され得る。いずれかの例において、ファイルシステムソフトウェアは、プロセッサおよびそのプロセッサが実行するハイレベルアプリケーションプログラムによる素早いアクセスのために、メモリ記憶装置ユニット内のデータを編成する。

従来のファイルシステムにおいて、ファイルシステムソフトウェアは、データファイル、および、ディレクトリと呼ばれる、対応するコンテナを含む階層構造における記憶装置ユニット内のデータを組織する。従来の階層構造は、ルートディレクトリと呼ばれる開始ディレクトリを有する、逆さまの樹形の形式である。追加的なディレクトリおよびファイルは、ルートディレクトリに依存し得る。追加的なディレクトリは、さらなるサブディレクトリおよびファイルを含み得る。

ファイルシステムソフトウェアは、システムにおけるそれぞれのファイル／ディレクトリエントリの名前および属性を把握するために使用されるレコードを含む、一つ以上のメタファイルを維持する。これらの属性は、例えば、エントリがデータファイルまたはディレクトリ、読み出し専用ファイル、隠しファイル、システムファイルなどであるかどうかなどを含む。記憶装置ユニットに格納されたファイルデータに物理的にアクセスするために必要とされる情報はまた、メタファイルにおけるレコードに含まれ得るか、またはそれによって示され得る。

ファイルシステムが従来のファイルシステム階層を用いて組織される場合、プロセッサは、任意の変化がデータファイルまたはディレクトリになされた場合に、メタファイルにおける相当の数の異なるレコードを更新しなければならない。メタファイルレコードを更新することは、例えば、ファイルまたはディレクトリが作成され、リネームされ、または、一つのディレクトリから別のディレクトリへ移動したときなどはいつでも、生じなければならない。これらの状況の下で更新されなければならないメタファイルにおける相当の数の異なるレコードは、例えば、システムが停電あるいは他のハードウェアまたはソフトウェアの故障を経験する場合、所与のレコードに対する更新が生じない可能性を増加させる。さらに、そのような故障の後のファイルシステムの再構成は、ファイルが従来の方法において組織される場合、複雑になり得、および多大な時間を要するものとなり得る。従って、従来のファイルシステム階層に対する代替案が必要とされる。

従来のファイルシステム階層を改良するコンピュータシステムが開示される。コンピュータシステムは、プロセッサ、およびそのプロセッサによってアクセス可能である固定データ記憶装置を含む。システムはまた、プロセッサによって実行されるファイルシステムソフトウェアを含み得る。ファイルシステムソフトウェアは、固定データ記憶装置のファイルを、メタファイルに含まれる複数のレコードへと組織するように動作し得る。メタファイル内において、ファイルシステムのファイルおよびディレクトリは、逆階層構造において組織され得る。逆階層構造において、親ディレクトリの子ファイルおよび子ディレクトリに対応するレコードは、その親ディレクトリに対応するメタファイルにおけるレコードを直接、示す（ｐｏｉｎｔｔｏ）。ファイルシステムの一インプリメンテーションにおいて、メタファイルの個々のレコードは、ファイル識別子によってそれぞれアドレス可能であり得る。個々のレコードのそれぞれは、その親ディレクトリレコードのファイル識別子に対応する親識別子を含み得る。

メタファイルにおけるレコードによって表されるファイル／ディレクトリに関連するトランザクションは、所望される場合、他の関連する親または子レコードの対応する修正なしで、自動的に実行され得る。最適化されたインプリメンテーションにおいて、単一のメタファイルレコードは更新され得、そこにおいて、ファイルまたはディレクトリは作成され、リネームされ、または、一つのディレクトリから別のディレクトリへ移動する。

ファイルシステムの逆階層構造はまた、必要に応じて、直ちに拡張され得、メタファイルにおけるファイルまたはディレクトリレコードに関連する情報量を増加する。例えば、それぞれのメタファイルレコードは、メタファイルに格納され得る、対応する拡張されたファイルレコードを示す、拡張されたファイル識別子を含み得る。拡張されたデータは、メタファイルにおける単一のファイルまたはディレクトリに割り当てられたメモリスペース内に適合することができない、ファイルまたはディレクトリに対応する、追加的な情報を含み得る。

フィイルシステムの逆階層構造はまた、トランザクションベースのシステムにおける使用のために適しており、特に、システムのためのトランザクションファイルがフラッシュメディアに格納されているものが適している。一つのそのようなトランザクションベースのシステムにおいて、ファイルシステムの再構成されたバージョンは、システムのスタートアップの間、ランダムアクセスメモリにおいて生成され得る。再構成されたファイルシステムは、メタファイルに格納されたファイルおよびディレクトリレコードから、少なくとも部分的に生成され得る。メタファイルにおけるレコードは、逆階層構造において組織され、逆階層構造は、効率的なスタートアップ動作を容易にし、再構成されたファイルシステムの生成を最適化するために使用され得る。

本発明は、さらに以下の手段を提供する。

（項目１）
プロセッサと、
該プロセッサによってアクセス可能な固定データ記憶装置と、
該プロセッサによってアクセス可能な少なくとも一つのメタファイルであって、該メタファイルは、該固定データ記憶装置上のファイルおよび該ファイルのためのディレクトリコンテナに対応する複数のレコードを有する、メタファイルと
を備え、
該複数のレコードの該個々のレコードは、ファイル識別子によってそれぞれアドレス可能であり、該個々のレコードは親識別子を含み、所与のレコードの該親識別子が、該所与のレコードのための親ディレクトリレコードの該ファイル識別子に対応する、
コンピュータシステム。

（項目２）
上記複数のレコードのそれぞれが固定された長さを有する、項目１に記載のコンピュータシステム。

（項目３）
上記複数のレコードのそれぞれが、拡張されたレコード識別子をさらに含み、
所与のレコードのための該拡張されたレコード識別子は、上記メタファイルにおける拡張されたレコードのファイル識別子に対応し、該拡張されたレコードが、該所与のレコードによって表される該ファイルまたはディレクトリに関連するさらなる情報を含む、項目１に記載のコンピュータシステム。

（項目４）
上記拡張されたレコードが、該拡張されたレコードによって表されたファイルまたはディレクトリの長い名前に対応する複数のＡＳＣＩＩ文字をさらに含む、項目３に記載のコンピュータシステム。

（項目５）
所与の拡張されたレコードの上記親識別子が、上記所与のレコードをアドレスする拡張されたレコード識別子を有するレコードの上記ファイル識別子に対応する、項目３に記載のコンピュータシステム。

（項目６）
複数のレコードエントリのそれぞれが、上記レコードによって表されたファイルまたはディレクトリの短い名前に対応する複数のＡＳＣＩＩ文字をさらに含む、項目１に記載のコンピュータシステム。

（項目７）
上記複数のレコードエントリのそれぞれが、
上記レコードに対応するファイルのタイプの情報を含むモードフィールドと、
該レコードに対応する該ファイルが最後にアクセスされた時間の情報を含むアクセス時間フィールドと、
該レコードに対応する該ファイルが最後に修正された時間の情報を含む修正時間フィールドと
をさらに備える、項目１に記載のコンピュータシステム。

（項目８）
プロセッサと、
該プロセッサによってアクセス可能な固定データ記憶装置と、
該プロセッサによって実行されるファイルシステムソフトウェアと
を備える、コンピュータシステムであって、
該ファイルシステムソフトウェアは、該固定データ記憶装置のファイルを、少なくとも一つのメタファイルに含まれる複数のレコードに組織するように動作し、該ファイルシステムソフトウェアは、親ディレクトリの子ファイルおよび子ディレクトリに対応するレコードが、該親ディレクトリに対応するメタファイルにおけるレコードを直接示す逆階層構造において、該メタファイルにおける該ファイルおよびディレクトリを組織する、
コンピュータシステム。

（項目９）
上記複数のレコードのそれぞれが固定された長さを有する、項目８に記載のコンピュータシステム。

（項目１０）
上記複数のレコードのそれぞれが、拡張されたレコード識別子をさらに含み、
所与のレコードのための該拡張されたレコード識別子が、上記メタファイルにおける拡張されたレコードのファイル識別子に対応し、該拡張されたレコードが、該所与のレコードによって表される上記ファイルまたはディレクトリに関連するさらなる情報を含む、項目８に記載のコンピュータシステム。

（項目１１）
上記拡張されたレコードが、該拡張されたレコードによって表されたファイルまたはディレクトリの長い名前に対応する複数のＡＳＣＩＩ文字をさらに含む、項目１０に記載のコンピュータシステム。

（項目１２）
所与の拡張されたレコードの上記親識別子が、上記所与のレコードをアドレスする拡張されたレコード識別子を有するレコードの上記ファイル識別子に対応する、項目１０に記載のコンピュータシステム。

（項目１３）
上記複数のレコードエントリのそれぞれが、上記レコードによって表されるファイルまたはディレクトリの短い名前に対応する複数のＡＳＣＩＩ文字をさらに含む、項目８に記載のコンピュータシステム。

（項目１４）
上記複数のレコードエントリのそれぞれが、
上記レコードに対応するファイルのタイプの情報を含むモードフィールドと、
該レコードに対応する該ファイルが最後にアクセスされた時間の情報を含むアクセス時間フィールドと、
該レコードに対応する該ファイルが最後に修正された時間の情報を含む修正時間フィールドと
をさらに備える、項目８に記載のコンピュータシステム。

本発明の他のシステム、方法、特徴および利点は、以下に続く図面および詳細な記載の検討において、当業者にとって明らかである。そのような追加的なシステム、方法、特徴、および利点は、本記載内に含まれ、本発明の範囲内であり、添付の特許請求の範囲によって保護されるべきことが意図される。

本発明は、添付の図面および記載を参照してより良く理解され得る。図における構成要素は、必ずしも縮尺通りである必要はなく、その代わり、本発明の原理を例示することに強調が置かれる。さらに、図において、同様の参照番号は様々な図を通して、対応する部分を示す。

図１は、例示的なトランザクションベースのコンピュータシステム１０において用いられ得る構成要素を示す。示されるように、例示的なシステム１０は、プロセッサ１５、読み出し専用メモリ２０、および固定記憶装置ユニット３０を含む。コンピュータシステム１０はまた、ランダムアクセスメモリ３５、Ｉ／Ｏインターフェース４０、およびユーザインターフェース４５を含み得る。コンピュータシステム１０において使用される特定の構成要素は、コンピュータシステム１０によって実行される特定の機能に対して変更され得る。従って、プロセッサ１５以外の構成要素の存在または不在は、コンピュータシステム１０に課される設計基準に対して特定的であり得る。例えば、コンピュータシステム１０が内蔵のコントローラなどの形式をとる場合、ユーザインターフェース４５は省かれ得る。

読み出し専用メモリ２０は、プロセッサ１５によって実行されるハイレベルのアプリケーションプログラムと、メモリデバイス２０および３５、固定記憶装置ユニット３０、ならびに、インターフェースデバイス４０および４５を含む、様々なハードウェア構成要素との間の遣り取りを制御する、オペレーティングシステムコード４３を含み得る。オペレーティングシステムコード４３は、固定記憶装置ユニット３０上に格納されたファイルを編成するためのファイルシステムソフトウェアを含み得る。あるいは、ファイルシステムソフトウェアは、オペレーティングシステムコード４３と単に遣り取りするする別個のソフトウェア構成要素として提供され得る。後者の場合において、ファイルシステムソフトウェアに対応するコードは、読み出し専用メモリ２０、固定記憶装置ユニット３０などに格納され得る。コンピュータシステム１０がＩ／Ｏインターフェース４０を介して、他のコンピュータおよび／または記憶装置とネットワーク化される場合、ファイルシステムソフトウェアは、遠隔に格納され得、必要に応じて、コンピュータシステム１０へダウンロードされ得る。しかしながら、図１は、読み出し専用メモリ２０におけるファイルシステムソフトウェア４７の格納を例示する。

固定記憶装置ユニット３０は任意の数の異なる形式を取り得る。例えば、固定記憶装置ユニット３０は、ハードディスクドライブ、フロッピー（登録商標）ディスクドライブ、などの形式を取り得る。また、集積回路形式（例えば、フラッシュメモリなど）においてインプリメントされる不揮発性メモリなどの、非回転式メディアデバイスの形式であり得る。さらに、固定記憶装置ユニット３０は単一のメモリ構造に限定される必要はない。むしろ、固定記憶装置ユニット３０は、多数の同様のタイプ（例えば、全てのフラッシュメモリ）の別個の記憶装置、および／または多数の異なるタイプ（例えば、一つ以上のフラッシュメモリユニットおよび一つ以上のハードディスクドライブ）の別個の記憶装置を含み得る。

固定記憶装置３０に格納されたファイルは、アプリケーションプログラムによってか、またはオペレーティングシステムコード４３によって使用される所定のフォーマットに従って解釈されるデータを含む。例えば、ファイル内に格納されたデータは、実行可能なプログラム、データベースレコードのＡＳＣＩＩテキスト、コンピュータシステム１０によって実行される（または実行されない）トランザクションに対応するデータなどのソフトウェアコードを構成し得る。

この例示的なシステム１０において、ファイルシステムソフトウェア４７は、逆階層構造を使用した固定記憶装置ユニット３０に格納されたファイルを組織する。図２は、全体が、参照番号５０にて示される逆階層構造がインプリメントされ得る一方法を示す図である。多くのファイルシステムによって使用される従来の階層構造において、ファイル構造の最上位はルートディレクトリから始まり、それぞれのディレクトリは、そのディレクトリ内に含まれるファイルおよびサブディレクトリへ下がっていく。例示的な逆階層構造５０においては、しかしながら、親ディレクトリ内に含まれる子ファイルおよび子ディレクトリは、親ディレクトリに上がっていく。ファイルシステムがどこでその編成を開始するかに依存しつつ、ルートディレクトリは、ファイルシステム構造の最下位レベルを構成し得る。

例示的な逆階層構造５０は、ファイルシステム構造の最上位レベルにおける、５つのファイル、５５、６０、６５、７０、および７５を含む。ファイル５５、６０、および６５はディレクトリ８０内に含まれる一方で、ファイル７０および７５はディレクトリ８５内に含まれる。従って、ファイルシステムソフトウェア４７は、子ファイル５５、６０、および６５を表すファイルシステムレコードがそれらの親ディレクトリ８０に対するレコードに示すように、ファイルシステムを編成する。同様に、子ファイル７０および７５を表すファイルシステムレコードは、それらの親ディレクトリ８５に対するレコードを示す。

例示的な逆階層構造５０の次なるレベルにおいて、ファイル９０、９５およびディレクトリ８０はディレクトリ１００内に含まれ、一方で、ディレクトリ８５はディレクトリ１０５内に含まれ得る。従って、ファイルシステムソフトウェア４７は、子ディレクトリ８０、ならびに子ファイル９０および９５を表すファイルシステムレコードがそれらの親ディレクトリ１００に対するレコードに示すようにファイルシステムを編成する。同様に、子ディレクトリ８５を表すファイルシステムレコードは、その親ディレクトリ１０５に対するレコードを示す。

ルートディレクトリ１１０は、逆階層構造５０のトランク（ｔｒｕｎｋ）を形成し得る。この例において、ディレクトリ１００および１０５、ならびにファイル１１５は、ルートディレクトリ１１０内に含まれる。ファイルシステムソフトウェア４７は、子ディレクトリ１００および１０５ならびに子ファイル１１５を表すファイルシステムレコードがそれらの親ディレクトリ１０５に対するレコードを示すように、ファイルシステムを編成する。

ファイルシステムソフトウェア４７が逆階層構造をインプリメントするためにファイルシステムのレコードを編成し得る一方法が、図３において示される。ファイルシステムのこのインプリメンテーションにおいて、ファイルシステムソフトウェア４７は、そのファイルシステムにおいて使用されるそれぞれのファイルおよびディレクトリに対応するレコードを含む一つ以上のメタファイルを生成し得る。図３は、単一のメタファイル１２０、および、そのメタファイル１２０内のレコードが配置され得、フォーマットされ得る例示的な方法を示す。この例において、メタファイル１２０は、複数の等しい長さのレコードエントリ１２５を含むテーブルとして配置され得る。それぞれのレコードエントリ１２５は、ファイルシステムにおいて使用され得る単一のファイルまたはディレクトリに対応する。参照番号１３０にて示される独自のファイル識別子は、ファイルシステムソフトウェア４７によって使用され得、メタファイル１２０の対応するレコード１２５をアドレスする。それぞれのレコードエントリ１２５が同じレコード長を有する場合、ファイル識別子１３０のフォーマットは、それが、メタファイル１２０における所望のレコードに対するインデックスとして、直接にかまたは間接的に使用され得るように、選択され得る。例えば、ファイル識別子１３０は、所望のディレクトリ／ファイル情報を有するメタファイルレコードの最初のバイトのメモリアドレスロケーションを計算するために、メタファイル１２０の最初のレコードのメモリアドレスロケーションと供に使用され得るオフセット値を構成し得る。

図３の例において、ファイル識別子１３０は、メタファイル１２０におけるレコード１３５（エントリ７）を示す。レコード１３５は、メタファイル１２０に隣接し、拡張形式において、図３に示される。レコード１３５の拡張形式はまた、それぞれのレコードエントリ１２５に対して使用され得る基本的なレコードフォーマットを示す。この例において、レコード１３５は、レコードによって表されるファイルまたはディレクトリに関連する情報を含む、多数の異なるフィールドを含む。他のものの中でも、この情報は、ファイルシステムの構造内におけるファイルまたはディレクトリの論理的ロケーションに対応する。

ファイルシステムの逆階層構造は、それぞれのメタファイルレコードがその親ディレクトリを表すメタファイルレコードに対するポインタを含む、メタファイルレコードフォーマットを用いることによってインプリメントされ得る。図３は、それぞれのメタファイルレコードが、その親ディレクトリのファイル識別子を格納する親識別子フィールド１４０を含む、メタファイルレコードフォーマットを示す。この例において、メタファイルレコード１３５の親レコード識別子１４０は、レコード１４５（エントリ９）をアドレスするために使用されるファイル識別子に対応する。次に、レコード１４５は、レコード１３５によって表されるファイルまたはディレクトリを含むディレクトリに関連する情報を含む。

それぞれのメタファイルレコードはまた、そのレコードが表すディレクトリまたはファイルに関連する他の情報を含み得る。レコード１３５の例示的なレコードフォーマットにおいて、多くの異なる情報フィールドが用いられる。情報フィールドは、モードフィールド１５０、ユーザ識別フィールド１５５、グループ識別フィールド１６０、アクセス時間フィールド１６５、修正時間フィールド１７０、作成時間フィールド１７５、ファイルサイズフィールド１８０、および短い名前フィールド１８５を含む。モードフィールド１５０は、レコードによって表されるファイルまたはディレクトリが、システムファイル／ディレクトリ、隠しファイル／ディレクトリ、読み出し専用ファイル／ディレクトリなどであるかどうかを決定するために使用され得る。ユーザ識別フィールド１５５およびグループ識別フィールド１６０は、表されたファイルまたはディレクトリのユーザおよびグループ所有権（ｏｗｎｅｒｓｈｉｐ）に関連する情報を含む。アクセス時間フィールド１６５、修正時間フィールド１７０、および作成時間フィールド１７５は、それぞれ、表されたファイルまたはディレクトリが最後にアクセスされた時間、表されたファイルまたはディレクトリが最後に修正された時間、および表されたファイルまたはディレクトリが作成された時間に関連する情報を含む。サイズフィールド１８０は、レコードによって表されたファイルのサイズに関する情報を含み、ディレクトリレコードに対してゼロである。最後に、短い名前フィールド１８５は、対応するファイルまたはディレクトリの短いテキスト名を表すＡＳＣＩＩ文字を含む。短い名前フィールド１８５の長さは、例えば、ＰＯＳＩＸ規格に適合するように選択され得る。付け加えて、それぞれのレコードは、短い名前に対応する、ハッシュ値および／または名前の要約（ｓｕｍ）を含み得る。そのようなハッシュ値および／または名前の要約は、特定のディレクトリおよび／またはファイルレコードを迅速に検索（ｓｅａｒｃｈ）するために、ファイルシステムソフトウェア４７によって使用され得る。

メタファイル１２０におけるそれぞれのレコードはまた、拡張レコード識別子１９０に対するフィールドを含み得る。拡張レコード識別子１９０は、メタファイル１２０における拡張レコードを示すファイル識別子として使用され得る。拡張レコードは、レコードによって表されるファイルまたはディレクトリに対するさらなる情報を含み得、特定のファイルまたはディレクトリに関連する情報の全てが、単一のメタファイルレコードに対して割り当てられるメモリスペース内に適合しない場合において、特に有用であり得る。

図３は、拡張レコード識別子１９０が使用され得る一方法を示す。この例において、レコード１３５の拡張レコード識別子１９０は、メタファイル１２０におけるレコード１９５（エントリ１１）にアクセスするために使用されるファイル識別子（ｆｉｄ）に対応する。レコード１９５の開いた展開図が、図３におけるレコード１３５の開いた展開図に隣接して示される。この開いた展開図が、拡張レコードに対して使用され得る一つのレコードフォーマットを示す。示されるように、それぞれの拡張レコードは、それ自体の親識別子フィールド２００を含み得る。拡張レコードの親識別子フィールド２００は、しかしながら、拡張レコードを示すレコードのファイル識別子に対応する。図３に示された例において、親識別子フィールド２００のコンテンツが、レコード１３５（エントリ７）に戻るために使用され得る。

二つのレコードエントリに割り当てられたメモリスペースがファイルまたはディレクトリに関連する情報の全てを保持するには不十分であるような場合において、拡張レコード１９５は、レコード１９５のフィールド２０５に含まれるような、それ自体の拡張レコード識別子を使用するさらなる拡張レコードを示し得る。拡張レコード識別子１２５によって示された、さらなる拡張レコードのフォーマットはここでは示されないが、さらなる拡張レコードは、同様に、レコード１９５に戻る親レコード識別子を含み得る。

拡張レコードに含まれる情報のタイプは、ファイルシステム間で変化し得る。図３において、拡張レコード１９５は、レコード１３５によって表されるファイルまたはディレクトリの長い名前のテキストに対応するＡＳＣＩＩ文字を含む、長い名前フィールド２１０を含む。さらなるフィールドは、レコード１９５などのような、それぞれの拡張レコードの拡張領域２１５において、予約され得、対応するファイルまたはディレクトリに関連する追加的な情報を格納する。

前述の例において、ファイルシステムに使用される拡張レコードは、メタファイル１２０において格納される。しかしながら、拡張レコードおよび任意のさらなる拡張レコードは、代替的に、別個のメタファイル、多数のメタファイルなどに格納され得る。別個のメタファイルは、同様の記憶装置媒体を、メタファイル１２０とも、相互にも、共有する必要はない。むしろ、メタファイルは、プロセッサ１５にアクセス可能である異なる記憶装置媒体に格納され得る。基本的なメタファイルレコード（対応する拡張レコードを有しないディレクトリおよびファイルレコード）でさえも、多数のファイルおよび／または多数の記憶装置媒体の中において分配され得る。従って、例示的なシステムのメタファイルレコードは単一のメタファイルに格納されるが、そのメタファイルは、代替的には、同一の、または異なる記憶装置媒体上の多くの個々のファイルという形式であり得る。

逆階層構造におけるコンピュータシステム１０のファイルおよびディレクトリを編成することによって、一つ以上のファイルシステムの利点を実現することが可能になる。例えば、ファイルシステムは、通常のファイルおよびディレクトリトランザクション（すなわち、ファイル／ディレクトリの移動、ファイル／ディレクトリの消去、ファイル／ディレクトリの作成、ファイル／ディレクトリのコピー）が、自動的に、単一のメタファイルレコードの変化、追加、または消去として達成される任意の方法においてインプリメントされることが可能である。このインプリメンテーションにおいて、例えば、レコード１３５によって表されるファイル／ディレクトリは、単に親識別子１４０を変化させることによって、階層における別のディレクトリに移動し得、その結果、それは、新しい親ディレクトリに対するメタファイルレコードを示す。これは、メタファイル１２０におけるレコード１３５に対する単一の書き込み動作を用いて達成され得る。

逆階層構造は、トランザクションまたはログベースのシステムを最適化するために用いられ得る。例示的なトランザクションまたはログベースシステムは、図１に示される構成要素から構成され得る。この例において、トランザクションファイル２２０は、固定記憶装置ユニット３０に維持され得、それぞれのファイルシステムのファイルおよびディレクトリに関連するトランザクションのレコードを保持するために使用され得る。ファイルシステムの更新は、トランザクションファイル２２０に含まれるトランザクションレコードに基づいて、自動的になされる。最も単純な形式の一つにおいて、全てのトランザクションレコードは、固定記憶装置ユニット３０の物理ブロックまたはセクターにマップされ得る単一の論理ページとして格納され得る。

トランザクションレコード２２５がコンピュータシステム１０における使用のためにフォーマットされ得る一方法が、図４に示される。一般的に言えば、トランザクションファイル２２０のそれぞれのトランザクションレコード２２５は、ヘッダフィールド２３０および対応のデータフィールド２３５を含む。ヘッダフィールド２３０は多数の異なるサブフィールドを含み得る。図４に示されるサブフィールドは、トランザクションシーケンスフィールド２４０、ファイル識別フィールド２４５、トランザクション状態フィールド２５０、クラスタハイ（ｈｉｇｈ）フィールド２５５、クラスタロー（ｌｏｗ）フィールド２６０、クラスタ数フィールド２６５を含む。付け加えて、さらなるサブフィールドが、トランザクションの保全性を認証し、エラーを修正するために、ヘッダ２３０において含まれ得る。これらのさらなるサブフィールドは、クラスタ要約フィールド２４７、トランザクション要約フィールド、ヘッダ２３０をチェックおよび修正するエラー修正コードフィールド２５７、データ２３５をチェックおよび修正するエラー修正コードフィールド２５９、および、トランザクションレコードが格納され得るメモリロケーションの状態を示すさらなる状態フィールド２６２を含む。

ヘッダフィールド２３０のサブフィールドのそれぞれは、ファイルシステムソフトウェア４７に対して意味を有する。この例において、トランザクションシーケンスフィールド２４０は、ファイルシステムソフトウェア４７によって割り当てられ得る、単調に増加するトランザクション識別子であり得る。新しいトランザクションレコードがトランザクションファイル２２０に追加され得る場合、新しいレコードのトランザクションシーケンスフィールド２４０において格納される値は、時間的に先行するトランザクションレコードのトランザクションシーケンスフィールドの値を超えた、所定の量だけ増加され得る。従って、大きなトランザクション識別子の値を有するトランザクションレコードほど、小さなトランザクション識別子の値を有するトランザクションレコードよりも、時間的に後の、トランザクションファイル２２０に追加されると考えられる。トランザクションシーケンスフィールド２４０（および所定の状況においては、トランザクションファイル２２０のブロック内におけるトランザクションレコードの位置）の値によって表されるような、このトランザクションの時間順の順序によって、ファイルシステムソフトウェア４７は、ファイルシステムのコンテンツの保全性を適切な順序に維持するために、トランザクションを適用する（すなわち、トランザクションをする）ことが可能である。トランザクションの時間的な順序の経過を追う他の方法もまた使用され得る。

ファイルシステムソフトウェア４７は、トランザクションレコード２２５のトランザクションがなされるかどうかを決定するために、トランザクション状態フィールド２５０を使用する。いったんトランザクションがなされると、そのなされたトランザクションレコード２２５のさらなる変更が、ファイルシステムソフトウェア４７によって禁止され得る。これはファイルシステムの整合性を保証し、ファイルシステムは、例えば、追記型メディア、フラッシュメディアなどにおいて、トランザクションファイル２２０を格納することができる。

ヘッダ２３０のファイル識別フィールド２４５は、トランザクションレコード２２５によって影響され得るファイルを識別する。ファイル識別フィールド２４５のフォーマットが、メタファイルレコードにおいて使用されるファイル識別子と同一であるように、選択され得る。クラスタハイフィールド２５５およびクラスタローフィールド２６０はファイルシステムソフトウェア４７によって使用され得、データ２３５が、識別されたファイルに書き込まれ得る開始アドレス（またはオフセット）を決定し、その一方で、クラスタ数フィールド２６５は、識別されたファイルのクラスタがいくつデータ２３５によって上書きされるかを決定するために使用され得る。

上述したように、固定記憶装置ユニット３０は、一つ以上のフラッシュメモリデバイスを含み得る。フラッシュメモリデバイスは、「メモリセル」と呼ばれる、論理ゲートにおける情報を格納し、それらのそれぞれは、通常、１ビットの情報を格納する。フラッシュメモリ技術におけるさらなる最近の発展によって、ときに、マルチレベルセルデバイスとも呼ばれるそのようなデバイスが、セル毎に１ビットよりも多くの以上を格納することが可能となっている。付け加えて、フラッシュメモリは不揮発性であり、それは、デバイスから電源が引き抜かれても、メモリセルのコンテンツは失われないことを意味する。

フラッシュメモリ技術が継続して進化しているが、優勢な技術としては、ＮＡＮＤフラッシュメモリおよびＮＯＲフラッシュメモリが挙げられる。ＮＯＲフラッシュデバイスおよびＮＡＮＤフラッシュデバイスは、一般に、それぞれの記憶装置セルに対して使用される論理ゲートのタイプにおいて異なる。ＮＡＮＤフラッシュメモリデバイス２７５のうちの一つのタイプの例示的な論理構成２７０が図５に示される。示されるように、デバイス２７５上の利用可能なメモリが、隣接する物理ブロック２８０に編成され得、それぞれが等しい数のメモリセルを有する（すなわち、１６Ｋバイト）。ＮＡＮＤフラッシュメモリデバイス２７５は、さらに、隣接するブロック２８０のそれぞれを、特定数の物理セクターまたはページ２９０に分割する。次に、それぞれの物理ページ２９０は、さらに、データ領域２９５およびスペア領域３００に分割され得る。データ領域２９５は、通常、データの格納のための予備であり、一方、スペア領域３００は、通常、データ領域２９５に格納されたデータについてのメタ情報の維持のために予約される。メタ情報としては、例えば、セクターのコンテンツの確認および修正のために使用されるエラー修正コード、巡回冗長検査データなどが挙げられ得る。

ＮＯＲフラッシュデバイスは、それぞれのページのスペア領域がデータ領域の反対側に位置する点を除いて、図５に示されるものと同様な構成を有する。ＮＯＲフラッシュデバイスはまた、ランダムアクセス読み出しおよびプログラミング動作を提供し、個々のメモリロケーションが読み出されるか、読み出すことが可能である。しかしながら、いったんブロックにおけるメモリロケーションが書き込まれると、ＮＯＲフラッシュデバイスは、そのブロックが、ブロックよりも小さい細分性にて再書き込みをされないようにする。同様に、ＮＯＲフラッシュデバイスは、ブロックよりもより小さい細分性における動作を消去させないようにする。

データ領域２９５およびスペア領域３００は、通常、ＮＯＲおよびＮＡＮＤフラッシュデバイスの両方における特定のサイズに設定される。例えば、図５の例示的なＮＡＮＤフラッシュデバイス２７５のそれぞれのページ２９０は、ページサイズ全体で５２８バイトに対して、５１２バイトのデータ領域２９５、および１６バイトのスペア領域３００を含む。ＮＡＮＤフラッシュデバイス２７５はまた、ブロック２８０毎に３２個のページ２９０を用いる。他のページサイズは、コンピュータシステム１０において使用され得、商業的にも利用可能である。例えば、多くのＮＡＮＤデバイスは、６４個のページを含むブロックを含み、そこで、それぞれのページは２１１２バイトを格納し、その結果、ページ毎のトータルのデータ領域は、２０４８バイトであり、ページ毎のスペア領域は６４バイトである。

ＮＡＮＤフラッシュデバイス２７５のようなフラッシュメモリデバイスは、通常、一度に、メモリのメモリブロック２８０全体上における消去動作を実行する。消去動作は、ブロック２８０内の全てのビットを、コンシステントな状態、通常はバイナリ「１」の値に設定する。フラッシュデバイス２７５の消去されたブロック２８０上におけるプログラミング動作は、ページ２９０全体のコンテンツを変更することができるのみである（ＮＯＲフラッシュデバイスは、僅かに異なる方法においてプログラムされ得るけれども）。いったんＮＡＮＤフラッシュデバイスのページ２９０がプログラムされると、その状態は、ブロック２８０全体が再び消去され得るまで、さらに変更され得ない。フラッシュデバイス２７５のコンテンツを読み出すことがまた、そのページレベルにおいて生じる。

図６は、トランザクションレコードがＮＡＮＤフラッシュデバイス２７５などのフラッシュメモリデバイスにおいて編成され得る一方法を示す。この例において、それぞれのトランザクションレコード３０５は、二つ以上の隣接した論理ページ３１５からなり得る。次に、それぞれの論理ページ３１５は、デバイス２７５のブロック２８０の、二つ以上の隣接した物理ページ２９０からなり得る。トランザクションレコード３１０に対するメタデータ情報は、スペア領域３００において格納され得、図４のヘッダ２３０と関連して記載されるフィールドの一部を含み得る。それぞれのページ２９０のスペア領域３００のサイズに依存しつつ、メタデータ情報は、トランザクションレコード３１０の多数のスペア領域３００において、分割され得る。二つの連続した物理ページ２９０のスペア領域３００間のメタデータ情報の分割が図６において示される。図６において示されるトランザクションレコードはまた、それぞれのトランザクション３１０が、単一の論理ページ３１５に対応し、単一の論理ページ３１５が、例えば、二つの隣接した物理ページ２９０からなり得るように、編成され得る。

フラッシュデバイス２７５における、それぞれの論理ページ３１５と物理ページ２９０との間の一対一対応が存在し得る代替的な配置が図７において示される。この配置と図６において示されるものの間の差異は、メタデータ情報３２０の全てが、トランザクション３１０の最初の物理ページ２９０の単一のスペア領域３００に格納され得る。このタイプの配置は、大容量のフラッシュデバイスが用いられる場合に、得に適切であり得る。しかしながら、メタデータ情報３２０はまた、トランザクションレコードの二つの隣接した物理ページ２９０のスペア領域３００間に分割され得る。

同一のデバイスブロック２９０において格納されたトランザクションレコード３１０に対するシーケンス識別子は同一の値を有し得る。そのような場合において、シーケンス識別子は、異なるデバイスブロックのトランザクションレコード間における時間関係を比較するために用いられ得る時間順の情報を提供する。同一のブロックにおいて格納されたトランザクションレコード３１０に関する時間順の情報は、ブロック２９０内のトランザクションレコード３１０のオフセットロケーションから引き出され得、後に、より大きなオフセットにて生じるトランザクションレコード３１０を生じる。

コンピュータシステム１０が開始されるか、電源をオンにされた後、ファイルシステムの保全性は、ランダムアクセスメモリ３５におけるファイルシステムの再構成されたバージョンを生成することによって確認され得る。図１の参照番号３３０において通常示されるように、再構成されたファイルシステムは、トランザクションファイル２２０において格納された有効になされたトランザクションを用いて、および、メタファイル１２０に格納されたファイル／ディレクトリ情報から、生成され得る。図１において、再構成されたファイルシステム３３０は、再生成されたファイル階層３３５およびエクステントテーブル３４０を含む。

エクステントプール３４０を生成する一方法は、図８から図１１において示される。図８は、エクステントプール３４０を生成するために使用され得る多数の相互に関連する処理ステップを示し、一方で、図９から図１１は、これらの動作において生成され、使用される様々なテーブルおよびアレイの論理編成を示す。

エクステントテーブル３４０の生成は、トランザクションレコードの全てを見出すために、トランザクションファイル２２０のブロックをスキャンすることによって、図８のステップ３４５において開始する。ブロックは、なされたトランザクションレコードが見出される、最も低い順序のブロックから最も高い順序のブロックの順にスキャンされ得る。トランザクションがブロック内に見出される場合、トランザクションレコードを有するそれぞれのデバイスブロックを識別するブロックレコードのアレイが、ステップ３５０において生成され得る。

ファイルシステムソフトウェア４７が、４つのトランザクションであるトランザクションファイル２２０のブロックをスキャンすると、ファイルシステムソフトウェアは、回収されたトランザクションの結果として消去されているブロックにあたり得る。これらのブロックは、ファイルシステムにおいて使用するために割り当てられていないからである。トランザクションヘッダは、通常バイナリ「１」である、消去された値に設定されたヘッダの全てのビットを有する有効なトランザクションが存在しないように、構成され得る。ファイルシステムソフトウェア４７がトランザクションファイル２２０のブロックをスキャンする場合、ヘッダが消去されたブロックを示す任意のトランザクションがスキップされ得る。このヘッダの不変量は、トランザクションはそれが消去された値の逆である場合にファイルシステムによって使用中であることを示すフラグとして、単一のビットを使用することによって、実行され得る。トランザクションヘッダにおける消去のサイン値を見出した後、ブロックにおける残りのページをスキャンすることはスキップされ得、それによって、さもなければ消去されたページにアクセスするために使用される時間を節約し得る。システムのスタートアップ時間全体が、それに対応して減少され得る。

例示的なブロックアレイ３５５の編成は図９において示される。それぞれのブロックアレイレコード３６０は、シーケンスフィールド３６５、開始トランザクションフィールド３７０、およびトランザクション数フィールド３７５を含む。シーケンスフィールド３６５は、ブロックにおいて格納されたトランザクションレコードに対する、トランザクション識別値を格納するために使用され得る。開始トランザクションフィールド３７０は、ブロックにおける第１のトランザクションに対するするインデックスを格納するために使用され得、トランザクション数フィールド３７５は、ブロックにおいて見出されるトランザクション数を格納するために使用され得る。

図８のステップ３８０において、ファイルシステムソフトウェア４７は、ブロックアレイ３５５におけるそれぞれのレコードエントリに対する、トランザクションリストテーブルを配置する。図９は、トランザクションリストテーブル３８５が編成され得る一方法を示す。この例において、ブロックアレイ３５５のそれぞれのレコード３６０は、トランザクションリストテーブル３８５の少なくとも一つのトランザクションリストレコード３９０を示す。より詳細には、トランザクションリストレコード３９０は、所定のブロックアレイレコード３６０によって表されるブロックにおいて見出されるそれぞれのトランザクションに対して生成され得る。所与のブロックアレイレコード３６０のトランザクション数フィールド３７５に格納された値は、所与のブロックにおけるトランザクション数に対応し、所与のブロックに対するレコード３９０がいくつトランザクションリストテーブル３８５に追加されるかを指定する。

トランザクションリストテーブル３８５のそれぞれのトランザクションリストレコード３９０は、同一のレコード長を有し得、同一のレコードフィールドを含み得る。図９のレコード３９０において使用される例示的なフィールドは、ファイルクラスタオフセットフィールド３９５、デバイスクラスタインデックスフィールド４００、クラスタ数フィールド４０５、およびファイル識別子／ｉｄｘフィールド４１０を含む。ファイルクラスタオフセットフィールド３９５は、ブロック内でのトランザクションの物理ロケーションを識別するために使用され得る。デバイスクラスタインデックスフィールド４００は、トランザクションのデータがどこで開始されるかを識別するために使用され得る。クラスタ数フィールド４０５は、どれくらいのデータのクラスタがそのトランザクション内に存在するかを識別するために使用され得る。最後に、以下で説明するように、ファイル識別子／ｉｄｘフィールド４１０は多目的である。しかしながら、最初に、ファイル識別子／ｉｄｘフィールド４１０において格納される値は、そのトランザクションが適用されるファイルを識別するために使用され得る。フィールド４１０において格納されるファイル識別子の値は、メタファイル１２０におけるレコードを基準にするために使用されるファイル識別子に直接に対応し得る。ステップ３８０が完了した後、ブロックアレイ３５５のレコード３６０は、例えば、ブロックの昇順において配置され、一方で、それぞれのブロックアレイレコード３６０に対するレコード３９０は、ページの昇順において配置される。

ステップ４１５において、ブロックアレイ３５５のレコード３６０は、シーケンスフィールド３６５において格納される値に基づいて、ソートされる。この動作は、時間順に（すなわち、対応するトランザクションがファイルシステムのファイルに適用される順）、トランザクションリストテーブル３８５のレコード３９０を配置するために実行され得る。

ファイルシステムのトランザクションレコードに対応するファイルノード情報を格納する一時ファイル４４０は、次いで、ブロックアレイ３５５のソートされたレコードおよびトランザクションリストテーブル３８５を用いて、ＲＡＭ３５において生成され得る。このため、ファイルシステムのルートディレクトリに対応する基本的なレコードは、最初に、一時ファイル４４０に追加され得る。一時ファイル４４０におけるルートディレクトリノードを生成するために使用される情報は、メタファイル１２０に格納されたルートディレクトリファイルに対応するレコードから得られ得る。

一時ファイル４４０においてファイルノードレコードを配置する一方法の論理表現は、全体が図１０の参照番号４４５として、示される。この例において、それぞれのファイルノードレコード４５０は、ファイルノードフィールド４５５および開始フィールド４６０を含む。ファイルノードフィールド４５５のコンテンツは、トランザクションリストテーブル３８５の様々なトランザクションレコード３９０がリンクされ得るファイルノードを識別するために使用され得る。明瞭さのために、ファイルノードフィールド４５５のコンテンツは、メタファイル１２０の、対応するレコードエントリ１２５にアクセスするために使用されるファイル識別子と同じフォーマットを有し得る。開始フィールド４６０のコンテンツは、ファイルノードフィールド４５５において識別されたファイルに対応するトランザクションリストテーブル３８５における第１のトランザクションレコード３９０のロケーションを識別するために使用され得る。従って、それぞれのファイルノードレコード４５０は、ファイルシステム内のファイル、および識別されたファイルに関連する第１のトランザクションのロケーションを識別する。

ステップ４２０において、ブロックアレイ３５５およびトランザクションリストテーブル３８５のそれぞれのソートされたレコード３６０および３９０は、ファイル識別子／ｉｄｘフィールド４１０に格納されたファイル識別子に対応するファイルノードレコード４５０を、一時ファイル４４０が含むかどうかを決定するために移動させる（ｔｒａｖｅｒｓｅ）。トランザクションレコード３９０と同じファイル識別子を有するファイルノードレコード４５０が一時ファイル４４０に見出されない場合、新しいファイルノードレコード４５０は、ステップ４３０において作成され得る。いったんトランザクションリストレコード３９０に対応するファイルノードレコード４５０が一時ファイル４４０において存在すると、トランザクションリストレコード３９０は、ファイルノードレコード４５０に対するトランザクションのリストにリンクされ得る。この例において、トランザクションリストレコード３９０は、図８のステップ４３５におけるファイルノードレコード４５０に対するトランザクションのリストにリンクされ得る。トランザクションリストレコード３９０がファイルノードに対するトランザクションのリストにリンクされ得る方法は、そのトランザクションリストレコード３９０が、ファイルノードの第１のトランザクションリストレコードであり得るか、または、ファイルノードに対する、その後のトランザクションリストレコードであり得るかに依存し得る。それがファイルノードの第１のトランザクションリストレコードである場合、ファイルノードレコード４５０の開始フィールド４６０は、この第１のトランザクションリストレコード３９０の開始ロケーションを識別するように更新され得る。従って、ファイルノードレコード４５０の開始フィールド４６０のコンテンツは、トランザクションリストテーブル３８５におけるロケーションを示すために使用され得、トランザクションリストテーブル３８５は、そのファイルに適用された第１のトランザクションに対するエクステント情報を含む。ファイル識別子／ｉｄｘフィールド４１０の機能は、トランザクションリストレコード３９０がファイルノードに対する現行のトランザクションリストレコードに追加され得る場合（すなわち、それがファイルノードに対する第１のトランザクションリストレコードではない場合）、変更される。より詳細には、フィールド４１０の値と機能は、それがファイルノードに関連する最後のトランザクションレコード３９０を示すために、変更され得る。これは図１０において例示され、そこで、ファイルノードレコード４５０の開始フィールド４６０は、トランザクションリストレコード３９０の開始を示す。レコード３９０のファイル識別子／ｉｄｘ４１０は、次に、トランザクションリストレコード４６５の開始を示し、トランザクションリストレコード４６５は、ファイルノードレコード４５０によって表されるファイルに対する第２のトランザクションのロケーション上の情報を含む。同様に、ファイルノードレコード４７０の開始フィールド４６０は、トランザクションリストレコード４７５の開始を示す。トランザクションリストレコード４７５のファイル識別子／ｉｄｘフィールド４１０は、トランザクションリストレコード４８０の開始を示し、トランザクションリストレコード４８０は、ファイルノードレコード４７０によって表されるファイルに対する第２のトランザクションのロケーションに関する情報を含む。

いったん、トランザクションリストテーブル３８５のトランザクションリストレコードの全てが、対応するファイルノードレコードと適切な方法にてリンクされると、それぞれのファイルノードに対するトランザクションリストレコードがステップ４８５に移動し、未遂および／または誤ったファイルトランザクションを参照とする任意のトランザクションリストレコードを取り除く。そのようなトランザクションリストレコードの除外は、様々な異なる方法において達成され得る。例えば、ファイルシステムソフトウェア４７は、それがなされたかどうかを決定するために、最後に生じたトランザクションの状態フィールドをチェックし得る。そのトランザクションがなされていた場合、トランザクションリストテーブル３８５における対応するレコードは、分配されないままであり得る。しかしながら、トランザクションが未遂である場合、トランザクションリストテーブル３８５における対応するレコードは、取り除かれ得るか、さもなければ、無視され得る。

トランザクション遂行の検査のこのタイプを促進するために、ファイルシステムソフトウェア４７は、最後に生じたトランザクションがなされたことを確認する必要があるのみである。他の全てのレコードの遂行検査はスキップされ得る。というのも、最後に生じたトランザクションのみは、停電、不正なシステムのシャットダウンなどの影響を受けるからである。他の全てのレコードの遂行検査をスキップすることによって、システムのスタートアップに必要とされる時間は、大幅に低減され得る。

直線的なシーケンスの一部として示されているが、ステップ４８５は、それぞれのトランザクションリストレコードがその対応するファイルノードを組み入れるために処理され得るように、実行され得る。例えば、ファイルシステムソフトウェア４７は、そのトランザクションがなされたかどうかを決定するために、それぞれのトランザクションレコードのヘッダに含まれる状態情報をチェックし得る。このチェックは、それぞれのトランザクションレコードが、対応するトランザクションリストレコードを配置するために使用され得る場合に、生じ得る。いったんファイルシステムソフトウェア４７が未遂のトランザクションを見出す場合、図８のステップ４２０〜ステップ４８５におけるトランザクションリストテーブル３８５のさらなる処理は必要とされない。

ステップ４９０において、それぞれのファイルノードに対するエクステントプール３４０においてエントリが生成される。これが達成され得る一つの方法は、図１１において示される。この例において、それぞれのファイルノードの開始フィールド４６０のコンテンツは、それがここでエクステントインデックスフィールド４８７として動作するように、変化され得る。エクステントインデックスフィールド４８７は、ファイルの第１のトランザクションに対するトランザクションデータのロケーションの情報を含むエクステントプール３４０における第１のロケーションを示す。それぞれのエクステントレコード４９０は、クラスタ数フィールド４９５、開始クラスタフィールド５００、および次のエクステントフィールド５０５を含み得る。開始クラスタフィールド５００は、デバイス２７０における開始ロケーションを識別し、そこで、ファイルノードに対応するファイルの第１のファイルトランザクションが格納され得る。クラスタ数フィールド４９５は、どれくらい多くの隣接するデバイス２７０のクラスタがファイルトランザクションを格納するために使用されるかを識別する。次のエクステントフィールド５０５は、ファイルノードによって表されるファイルに対する次のエクステントレコードのエクステントインデックスを識別する。この例において、エクステントインデックス４８７はエクステントレコード５１０を示し、その一方で、エクステントレコード５１０の次のエクステントフィールド５０５は、エクステントレコード５１５を示す。

エクステントプール３４０のレコードを配置するために使用されるデータは、トランザクションリストテーブル３８５において格納されるデータから、少なくとも一部、引き出され得る。ここで示される例において、エクステントプール３４０は、トランザクションリストテーブル３８５のさらにコンパクトな形式であり得る。このため、ファイルシステムソフトウェア４７は、トランザクションリストレコードが同一のファイルノードの一部である場合、隣接したデータを有するトランザクションリストレコードを単一のエクステントレコードエントリに組み合わせ得る。同様に、ＲＡＭ３５におけるブロックアレイ３５５を維持するさらなる必要は存在しない。それゆえ、ブロックアレイ３５５は、ＲＡＭ３５から取り除かれ得る。

トランザクションファイル２２０におけるトランザクションの保全性は、エクステントプール３４０を生成するために使用される様々なステップの実行の間、チェックされ得る。例えば、トランザクションレコードの保全性チェックは、図８のステップ３５０またはステップ３８０の間に実行され得る。通常のデータチェックは、ＣＲＣおよびＥＣＣ技術を含む。

コンピュータシステム１０のスタートアップ時間を低減するために、エラーチェック技術は、所定のトランザクションのヘッダに含まれる情報に制限され得る。トランザクションが図８において示されるスタートアッププロセスの間に見出される場合、ファイルシステムソフトウェア４７は、トランザクションが、メタファイル１２０におけるディレクトリ構造情報などのファイルデータまたはメタデータに影響を与えるかどうかを識別し得る。この区別は、トランザクションに関連するファイル識別子に基づき得る。通常、メタデータは、よく知られるファイル識別子によって表され、ファイルシステムソフトウェア４７にハードコードされる（例えば、それらは、メタファイル１２０を、トランザクションの主題（ｓｕｂｊｅｃｔ）であるファイルとして識別する）。メタデータのみが、ファイルシステムがスタートアップ後にコンシステントな状態にあることを確認するために要求されるゆえ、トランザクションのデータ部分のデータチェック技術は、トランザクションがそのようなメタデータに関連する場合のみ、実行される。トランザクションがメタデータの変化に関連しない場合、データチェック技術は、最初にヘッダ情報のチェックのみに限定され得る。図６に示されるトランザクションレコードフォーマットにおいて、システムスタートアップにおいて確認されなければならない主ヘッダ情報は、それぞれのトランザクションレコード３１０の第１のスペア領域３００において格納され得る。これにより、ファイルシステムソフトウェア４７は、それぞれのトランザクションレコード３１０の第２のスペア領域に含まれるヘッダ情報の認証をスキップすることができ、それによって、スタートアップシーケンスをさらに最適化することができる。以下でさらに詳細に説明するように、それぞれのトランザクションのデータ部分のエラーチェックは、対応するファイルが、スタートアップシーケンスの完了後に、ファイルシステムソフトウェア４７によって最初にアクセスされ得るまで、延期され得る。

トランザクションレコードの任意のスタートアップ認証は、一連の順序だったトランザクションの第１のトランザクションヘッダのみに、エラーチェックを制限することによってさらに最適化され得る。トランザクションファイル２２０のスタートアップスキャンの間、トランザクションヘッダが見出され、同一のファイルに対する多数の順序だったトランザクションレコードが後に続く場合、その順序における後続のトランザクションのヘッダの認証は、いったんシーケンスの第１のトランザクションレコードに対するヘッダが承認されると、スキップされ得る。ヘッダ情報のスキャンおよび認証は、次いで、後続のトランザクションの最後に続く次のブロックを回復し得る。

ＲＡＭ３５において、再構成されるファイルシステム３３０を生成することにおける次の広いステップは、再生成されたファイル階層３３５の構成であり得る。この例において、再生成されたファイル階層３３５は、ファイルおよびディレクトリノードレコードの両方からなり得る。ディレクトリノードレコードに対する例示的なフォーマットは、全体が、図１２の参照番号５２０に示され、一方、ファイルノードレコードに対する、対応する例示的なフォーマットは、全体が、図１３の参照番号５２５に示される。

ディレクトリノードレコード５２０は、ファイルシステムソフトウェア４７によって使用される多数の異なるフィールドを含む。より詳細には、ディレクトリノードレコード５２０は、兄弟フィールド５３０、ファイル識別子フィールド５３５、親識別子フィールド５４０、子フィールド５４５、およびディレクトリ名フィールド５５０を含み得る。同様に、図１３のファイルノードレコードは、ファイルシステムソフトウェア４７によって使用される多数の異なるフィールドを含む。ファイルノードレコードフィールドは、兄弟フィールド５５５、ファイル識別子フィールド５６０、エクステントインデックスフィールド５６５、および名前要約フィールド５７０を含み得る。

メタファイル１２０のレコードにおいて含まれるデータが、再生成されたファイル階層３３５の構成において使用され得るゆえ、メタファイルレコードがメタファイル１２０に配置される方法は、システムスタートアップの性能に影響を与える。このため、メタファイル１２０のレコードは、同じ長さを有する隣接したレコードとして、単一のメタファイルに配置され、同一の記憶装置媒体に全て格納される。この配置は、ファイルシステムソフトウェア４７がメタファイルにアクセスし得るスピードを向上させ、そのアクセスに必要とされる処理の量を低減させる。

再生成されたファイル階層３３５のそれぞれのファイルノードレコード５２５およびディレクトリノードレコード５２０に対するフィールドを配置するために使用され得る一連のステップは、図１４に示される。例示されたシーケンスは、メタファイル１２０においてそれぞれのレコードに対して実行され得、ステップ５７５において開始され得る。ステップ５７５において、ファイル識別子は、メタファイル１２０内における第１のレコードエントリのオフセットに基づいて、生成され得る。再生成されたファイル階層３３５のチェックは、ステップ５８０において、ファイル識別子に対応するファイルノードレコード５２５またはディレクトリノードレコード５２０が既に存在するかどうかを決定するために、なされ得る。対応するノードレコード５２０または５２５が存在しない場合、新しいレコードファイルが、再生成されたファイル階層３３５において作成され得る。新しく作成されたレコードのフォーマットは、ファイル識別子が、メタファイル１２０におけるファイルエントリまたはディレクトリエントリに対応するかどうかに依存する。ファイルシステムソフトウェア４７は、この決定をし、適切なレコードフォーマット５２０または５２５を適用する。

ステップ５８５において、新しく作成されたレコードに対するフィールドが、メタファイル１２０において見出されるファイル／ディレクトリに対する属性を使用し、配置される。新しく作成されたレコードが、ディレクトリノードに対応する場合、親識別子フィールド５４０およびディレクトリ名フィールド５５０は、メタファイル１２０における対応するレコードの親ファイル識別子および短い名前フィールドにおけるデータを使用して、配置される。新しく作成されたレコードがファイルノードに対応する場合、名前要約フィールド５７０は、メタファイル１２０における対応するレコードのファイル名データに直接格納されるか、またはそこから引き出されるデータを使用して、配置され得る。エクステントインデックスフィールド５６５は、対応するファイルノードレコード４５０のエクステントインデックスフィールド４８７に見出されるデータを使用して、配置され得る（図１１を参照）。

新しく作成されたファイルがディレクトリノードに対応する場合、再生成されたファイル階層３３５を介した検索が、親ノードが存在するかどうかを決定するために、ステップ５９０において試みられ得る。親ノードが存在しない場合、親ノードに対応するディレクトリレコードは、再生成されたファイル階層３３５に追加され得る。

ステップ５９５において、新しく生成されたファイル／ディレクトリレコードは、親ディレクトリノードに対する樹形構造にリンクされ得る。新しく生成されたファイル／ディレクトリレコードの子フィールド５４５が、親ディレクトリが子を有さないことを示す場合、親ディレクトリレコードの子フィールド５４５の値は、新しく生成されたファイル／ディレクトリレコードを示すように設定され得、その新しく生成されたファイル／ディレクトリレコードの兄弟フィールド５５５または５３０は、新しく生成されたファイル／ディレクトリレコードが兄弟を有さないことを示すように設定され得る。親ノードレコードの子フィールド５４５が、親ディレクトリノードが子を有さないことを示す場合、新しく生成されたファイル／ディレクトリレコードの兄弟フィールド５６５または５３０は、親ディレクトリの現行の子を示すように設定され得、親ディレクトリの子フィールド５４５は、新しく生成されたファイル／ディレクトリレコードを示すように設定され得る。新しく生成されたファイル／ディレクトリレコードがディレクトリノードに対応する場合、新しく生成されたディレクトリレコードの親識別子フィールド５４０は、親ディレクトリノードを示すように設定され得る。

ステップ６００において、ファイルシステムソフトウェア４７は、再帰的に、親ノードを上り、新しく生成されたファイル／ディレクトリレコードの親ディレクトリから開始され、ルートノードが到達されるまで、一連の処理ステップを実行する。この点において、新しく生成されたファイル／ディレクトリレコードの親ディレクトリノードは、カレントディレクトリノードとして呼ばれ得る。図１４において示される例示的なプロセスにおいて、ファイルシステムソフトウェア４７は、カレントディレクトリの親ノードに対応するディレクトリノードレコードが存在するかどうかを決定するために、再生成されたファイル階層３３５をチェックする。このプロセスは、ステップ６０５およびステップ６１０において実行され得る。そのようなディレクトリレコードが再生成されたファイル階層３３５に存在しない場合、新しいディレクトリレコードがステップ６１５において生成され得る。新しく生成されたディレクトリレコードの子フィールド５４５は、次いで、新しいディレクトリレコードの子のみとして、カレントディレクトリノードレコードを示すように設定され得る。ステップ６２０において、カレントディレクトリノードレコードの親識別子フィールド５４０は、新しく生成されたディレクトリレコードを示すように設定され得る。カレントディレクトリノードレコードの兄弟フィールド５３０は、ステップ６２５において、カレントディレクトリノードレコードに対する兄弟が存在しないことを示すように設定され得る。

ステップ６０５およびステップ６１０において実行されたチェックが、カレントディレクトリの親ノードに対応する、再生成されたファイル階層３３５におけるディレクトリレコードが存在することを示す場合、次いで、カレントディレクトリノードは、ステップ６３０において、親ディレクトリノードの生成された樹形構造にリンクされ得る。このため、カレントノードの親識別子フィールド５４０は、再生成されたファイル階層３３５における親ノードレコードのロケーションを示すように設定され得る。カレントディレクトリノードの兄弟フィールド５３０は、親ノードレコードの子フィールド５４５によって示されるのと同じレコードを示すように設定され得る。最後に、親ディレクトリノードの子フィールド５４５は、カレントディレクトリノードのロケーションを示すように設定され得る。

ステップ６３５において、ファイルシステムソフトウェア４７は、再帰的なディレクトリ処理が完了したかどうかを決定するためにチェックする。この例において、再帰的なディレクトリ処理は、その処理がルートノードを送信するときに、完了し、そのルートノードは、独自かつ認識可能なファイル識別子である。ルートノードがステップ６３５において到達される場合、メタファイル１２０における次のファイルレコードエントリは、ステップ６４０において開始され得、処理の制御はステップ５７５に戻る。ルートノードがステップ６３５において、到達しない場合、次いで、斜上型のファイル／ディレクトリ階層における次の親ノードの処理は、ステップ６０５において、始めから繰り返され得る。

図１５は、再構成されたファイルシステム３３０の論理表示であり、図２において示されたファイル階層を有するファイルシステムに対して、図８および図１４の処理ステップを適用することに対応する。この例示的な表示において、線６６５、６７０、６７５、および６８０は、それぞれ、ディレクトリ１０５、１００、８０、および８５を表すディレクトリノードレコードに対する、親識別子フィールド５４０のコンテンツに対応するポインタを表す。線６４５、６５０、６６０、および６５２は、それぞれ、ディレクトリ１１０、１００、１０５、８０および８５を表す、ディレクトリノードレコードに対する、子識別子フィールド５４５のコンテンツに対応するポインタを表す。線６８５、６９０、６９５、および７０５は、それぞれ、ディレクトリ１００、１０５、および８０に対応するディレクトリノードレコードに対する兄弟識別子フィールド５３０のコンテンツに対応するポインタを表す。線７００、７０５、７１０、および７１５は、それぞれ、ファイル９０、５５、６０、および７０に対応するファイルノードレコードに対する兄弟識別子フィールド５５５のコンテンツに対応するポインタを表す。

再構成されたファイルシステム３３０を使用した固定記憶装置ユニット３０のトランザクションファイル２２０におけるデータにアクセスする一方法はまた、図１５に示される。示されるように、ファイルシステムソフトウェア４７は、ソフトウェアがアクセスするファイルノードレコードに対して、ファイル識別子７３０を提供する。この例において、ファイル識別子７３０は、ファイル５５を表すファイルノードレコードを示す。ファイルシステムソフトウェア４７は、次いで、トランザクションファイル２２０におけるファイルに対するデータを配置するために、エクステントプール３４０へのインデックスとして、ファイルノードレコードのエクステントインデックス５６５のコンテンツを使用する。しかしながら、ファイルシステムソフトウェア４７は、図１５において示されるものとは異なる様々な異なる方法において、再構成されたファイルシステム３３０のコンテンツを使用し得る、ということは理解される。

上記したように、ファイルの保全の完全な認証は、スタートアップ処理が促進され得るために、スタートアップの間は実行されない。その代わり、ファイルシステムソフトウェア４７は、ファイルがアクセスされ得る最初の時間まで、ファイルの完全な認証を延期し得る。このため、ファイルシステムソフトウェア４７は、それぞれのファイルの保全が完全に認証されているかどうかを示すテーブルを維持し得る。あるいは、ファイルシステムソフトウェア４７は、ファイルの保全が完全に認証されたかどうかを示すために、再生成されたファイル階層３３５におけるそれぞれのファイルノードレコードの一つ以上のビットを使用し得る。このインジケータは、ファイルがスタートアップ後にアクセスされ得る、少なくとも最初の時間に、ファイルシステムソフトウェア４７によってチェックされ得る。インジケータが、ファイルが完全に認証されていないことを表す場合、ファイルの完全な認証は、その時点において実行され得る。あるいは、ファイルのトランザクションのヘッダが既にチェックされているゆえ、ファイルシステムソフトウェアは、ファイルに対するそれぞれのトランザクションのデータ部分の保全を認証する必要があるのみである。認証プロセスは、一つ以上のＣＲＣプロセス、一つ以上のＥＣＣプロセスなどを含み得る。

図５、図６、および図７に示されるように、それぞれのトランザクションレコードヘッダにおける多数の異なるフィールドが、トランザクションレコード全体の保全を認証することに専念され得る。保全性のチェックが失敗し、適切なエラー修正コードを使用するアプリケーションがエラーを修正できない場合、次いで、プログラムエラーは、ファイルコンテンツへのアクセスの要求をしたアプリケーションまたはシステムに報告され得る。

本発明の様々な実施形態が記載されているが、さらに多くの実施形態およびインプレメンテーションが本発明の範囲内にて可能であることは当業者にとって明らかである。従って、本発明は、添付された請求の範囲およびそれらの均等物の観点を除いて、限定されない。

逆階層構造を有するファイルシステムをインプリメントし得るコンピュータシステムのブロック図である。逆階層構造を有するファイルシステム内のファイルおよびディレクトリの配置の一例を示す樹形図である。逆階層構造を有するファイルシステム構造をインプリメントするように配置され得る一方法を示すブロック図である。トランザクションベースのコンピュータシステムのトランザクションファイルにおいて、トランザクションレコードを論理的に配置する一方法を示す。フラッシュメディアデバイスの一タイプにおけるメモリの物理的配置を示す。トランザクションレコードが、トランザクションベースのファイルシステムにおいて使用されるフラッシュメディアデバイスに配置され得る方法を示す。トランザクションレコードが、トランザクションベースのファイルシステムにおいて使用されるフラッシュメディアデバイスに配置され得る方法を示す。スタートアップの間に、コンピュータシステムによって作成される再構成されたファイルシステムにおいて用いられる、エクステントプールを生成するために使用され得る、相互に関連した多数の処理ステップを示す。図８において示された処理ステップにおいて使用される様々なレコードタイプに対する例示的なフォーマットに関する。図８において示された処理ステップにおいて使用される様々なレコードタイプに対する例示的なフォーマットに関する。図８において示された処理ステップにおいて使用される様々なレコードタイプに対する例示的なフォーマットに関する。再構成されたファイルシステムにおいて使用される再生成されたファイル階層のディレクトリノードレコードに対する例示的なフォーマットに関する。再構成されたファイルシステムにおいて使用される再生成されたファイル階層のファイルノードレコードに対する例示的なフォーマットに関する。再構成されたファイルシステムにおいて使用される再生成されたファイル階層を構成するために使用され得る相互に関連した多数の処理ステップを示す。図２に示される例示的なファイルおよびディレクトリ配置に適用されるように、図８〜図１４に関連して説明される方法において生成される再構成されたファイルシステムの論理表示である。

符号の説明

１０コンピュータシステム
１５プロセッサ
３０固定記憶装置ユニット
４７ファイルシステムソフトウェア
１２０メタファイル

Claims

プロセッサと、
該プロセッサによってアクセス可能な固定データ記憶装置と、
該プロセッサによってアクセス可能な少なくとも一つのメタファイルであって、該メタファイルは、該固定データ記憶装置上のファイルおよび該ファイルのためのディレクトリコンテナに対応する複数のレコードを有する、メタファイルと
を備える、コンピュータシステムであって、
該複数のレコードの該個々のレコードは、ファイル識別子によってそれぞれアドレス可能であり、該個々のレコードは親識別子を含み、所与のレコードの該親識別子が、該所与のレコードのための親ディレクトリレコードの該ファイル識別子に対応する、
コンピュータシステム。
前記複数のレコードのそれぞれが固定された長さを有する、請求項１に記載のコンピュータシステム。
前記複数のレコードのそれぞれが、拡張されたレコード識別子をさらに含み、
所与のレコードのための該拡張されたレコード識別子は、前記メタファイルにおける拡張されたレコードのファイル識別子に対応し、該拡張されたレコードが、該所与のレコードによって表される該ファイルまたはディレクトリに関連するさらなる情報を含む、請求項１に記載のコンピュータシステム。
前記拡張されたレコードが、該拡張されたレコードによって表されたファイルまたはディレクトリの長い名前に対応する複数のＡＳＣＩＩ文字をさらに含む、請求項３に記載のコンピュータシステム。
所与の拡張されたレコードの前記親識別子が、前記所与のレコードをアドレスする拡張されたレコード識別子を有するレコードの前記ファイル識別子に対応する、請求項３に記載のコンピュータシステム。
複数のレコードエントリのそれぞれが、前記レコードによって表されたファイルまたはディレクトリの短い名前に対応する複数のＡＳＣＩＩ文字をさらに含む、請求項１に記載のコンピュータシステム。
前記複数のレコードエントリのそれぞれが、
前記レコードに対応するファイルのタイプの情報を含むモードフィールドと、
該レコードに対応する該ファイルが最後にアクセスされた時間の情報を含むアクセス時間フィールドと、
該レコードに対応する該ファイルが最後に修正された時間の情報を含む修正時間フィールドと
をさらに備える、請求項１に記載のコンピュータシステム。
プロセッサと、
該プロセッサによってアクセス可能な固定データ記憶装置と、
該プロセッサによって実行されるファイルシステムソフトウェアと
を備える、コンピュータシステムであって、
該ファイルシステムソフトウェアは、該固定データ記憶装置のファイルを、少なくとも一つのメタファイルに含まれる複数のレコードに組織するように動作し、該ファイルシステムソフトウェアは、親ディレクトリの子ファイルおよび子ディレクトリに対応するレコードが、該親ディレクトリに対応するメタファイルにおけるレコードを直接示す逆階層構造において、該メタファイルにおける該ファイルおよびディレクトリを組織する、
コンピュータシステム。
前記複数のレコードのそれぞれが固定された長さを有する、請求項８に記載のコンピュータシステム。
前記複数のレコードのそれぞれが、拡張されたレコード識別子をさらに含み、
所与のレコードのための該拡張されたレコード識別子が、前記メタファイルにおける拡張されたレコードのファイル識別子に対応し、該拡張されたレコードが、該所与のレコードによって表される前記ファイルまたはディレクトリに関連するさらなる情報を含む、請求項８に記載のコンピュータシステム。
前記拡張されたレコードが、該拡張されたレコードによって表されたファイルまたはディレクトリの長い名前に対応する複数のＡＳＣＩＩ文字をさらに含む、請求項１０に記載のコンピュータシステム。
所与の拡張されたレコードの前記親識別子が、前記所与のレコードをアドレスする拡張されたレコード識別子を有するレコードの前記ファイル識別子に対応する、請求項１０に記載のコンピュータシステム。
前記複数のレコードエントリのそれぞれが、前記レコードによって表されるファイルまたはディレクトリの短い名前に対応する複数のＡＳＣＩＩ文字をさらに含む、請求項８に記載のコンピュータシステム。
前記複数のレコードエントリのそれぞれが、
前記レコードに対応するファイルのタイプの情報を含むモードフィールドと、
該レコードに対応する該ファイルが最後にアクセスされた時間の情報を含むアクセス時間フィールドと、
該レコードに対応する該ファイルが最後に修正された時間の情報を含む修正時間フィールドと
をさらに備える、請求項８に記載のコンピュータシステム。