JPH08278904A - 高性能ファイルシステム - Google Patents
高性能ファイルシステムInfo
- Publication number
- JPH08278904A JPH08278904A JP7354961A JP35496195A JPH08278904A JP H08278904 A JPH08278904 A JP H08278904A JP 7354961 A JP7354961 A JP 7354961A JP 35496195 A JP35496195 A JP 35496195A JP H08278904 A JPH08278904 A JP H08278904A
- Authority
- JP
- Japan
- Prior art keywords
- file
- directory
- sector
- volume
- computer system
- 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.)
- Pending
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
- G06F3/0608—Saving storage space on storage systems
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/13—File access structures, e.g. distributed indices
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/17—Details of further file system functions
- G06F16/178—Techniques for file synchronisation in file systems
- G06F16/1794—Details of file format conversion
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
- G06F3/061—Improving I/O performance
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0638—Organizing or formatting or addressing of data
- G06F3/0643—Management of files
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
- G06F3/0671—In-line storage system
- G06F3/0673—Single storage device
- G06F3/0674—Disk device
-
- G—PHYSICS
- G11—INFORMATION STORAGE
- G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
- G11B20/00—Signal processing not specific to the method of recording or reproducing; Circuits therefor
- G11B20/10—Digital recording or reproducing
- G11B20/12—Formatting, e.g. arrangement of data block or words on the record carriers
- G11B20/1217—Formatting, e.g. arrangement of data block or words on the record carriers on discs
- G11B20/1252—Formatting, e.g. arrangement of data block or words on the record carriers on discs for discontinuous data, e.g. digital information signals or computer program data
-
- G—PHYSICS
- G11—INFORMATION STORAGE
- G11B—INFORMATION STORAGE BASED ON RELATIVE MOVEMENT BETWEEN RECORD CARRIER AND TRANSDUCER
- G11B27/00—Editing; Indexing; Addressing; Timing or synchronising; Monitoring; Measuring tape travel
- G11B27/10—Indexing; Addressing; Timing or synchronising; Measuring tape travel
- G11B27/19—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier
- G11B27/28—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording
- G11B27/32—Indexing; Addressing; Timing or synchronising; Measuring tape travel by using information detectable on the record carrier by using information signals recorded by the same method as the main recording on separate auxiliary tracks of the same or an auxiliary record carrier
- G11B27/327—Table of contents
- G11B27/329—Table of contents on a disc [VTOC]
-
- 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
-
- 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/99956—File allocation
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Human Computer Interaction (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Signal Processing (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
(57)【要約】 （修正有）
【課題】 現在のファイルシステムより性能の勝ってい
る改良されたファイルシステム。 【解決手段】 第１のディスク フィールドがブート
ブロックを備え、これにつづいて第２のフィールドがス
ーパーブロックを、第３のフィールドがスペアブロック
を備える。複数のバンドがデータを記憶するための一連
の連続セクタを含み、各バンドはセクタ使用を示すフリ
ースペース ビット マップを含んでいる。ブートブロ
ックはボリューム ネーム、ボリュームＩ．Ｄ．そして
ディスク ブートストラップ プログラムを含んでい
る。スーパーブロックはフリースペース ビットマッ
プ、バッド ブロック リスト、デイクショナリ ブロ
ックバンドそしてルート デイクショナリへのポインタ
を含んでいる。ファイルとデイクショナリとはＦノード
構成にアンカーされている。それはセクタの続きを指し
ている複数のポインタから成る。
る改良されたファイルシステム。 【解決手段】 第１のディスク フィールドがブート
ブロックを備え、これにつづいて第２のフィールドがス
ーパーブロックを、第３のフィールドがスペアブロック
を備える。複数のバンドがデータを記憶するための一連
の連続セクタを含み、各バンドはセクタ使用を示すフリ
ースペース ビット マップを含んでいる。ブートブロ
ックはボリューム ネーム、ボリュームＩ．Ｄ．そして
ディスク ブートストラップ プログラムを含んでい
る。スーパーブロックはフリースペース ビットマッ
プ、バッド ブロック リスト、デイクショナリ ブロ
ックバンドそしてルート デイクショナリへのポインタ
を含んでいる。ファイルとデイクショナリとはＦノード
構成にアンカーされている。それはセクタの続きを指し
ている複数のポインタから成る。
Description
【産業上の利用分野】本発明はコンピュータ翻訳システ
ムの分野に関し、より詳しくは、コンピュータシステム
を備えた装置同士の通信を行う方法及び手段に関する。
なお、本明細書には、３８５個のフレームを含むマイク
ロフィッシュの４枚のシートからなる付録Ｉ（Ａｐｐｅ
ｎｄｉｘ Ｉ）が含まれている。
ムの分野に関し、より詳しくは、コンピュータシステム
を備えた装置同士の通信を行う方法及び手段に関する。
なお、本明細書には、３８５個のフレームを含むマイク
ロフィッシュの４枚のシートからなる付録Ｉ（Ａｐｐｅ
ｎｄｉｘ Ｉ）が含まれている。
【従来の技術】一般に、コンピュータシステムは、中央
処理装置と、ランダムアクセスメモリと、リードオンリ
メモリと、データ入力装置、データ出力装置、フロッピ
ディスク及び固定ディスク又はハードディスク等の種々
の不揮発性データ記憶装置等の種々の周辺装置とを有し
ている。一般に、それぞれの装置間の通信はコンピュー
タオペレーティングシステムにより制御される。良く知
られた１つのコンピュータオペレーティングシステムと
して、マイクロソフト社（Ｍｉｃｒｏｓｏｆｔ）から市
販されているＭＳ−ＤＯＳオペレーティングシステムが
ある。ＭＳ−ＤＯＳオペレーティングシステムにおいて
は、単一のファイルシステムが、周辺装置に記憶された
ファイルの編成を記載しかつ構成している。コンピュー
タシステム及びそれぞれの周辺装置の両者により認識さ
れたフォーマット中のデータをコンピュータシステムが
読み取り又は書き込みできるようにするには、データは
このファイルシステムに従って編成されなくてはならな
い。例えば、ＭＳ−ＤＯＳオペレーティングシステムに
使用される従来のフロッピディスクを用いた周辺装置に
おいては、フロッピディスクのデータは、ＦＡＴファイ
ルシステム（ファイル割当てテーブル（ｆｉｌｅ ａｌ
ｌｏｃａｔｉｏｎ ｔａｂｌｅ）を用いていることか
ら、このように命名されている）として知られているフ
ァイルシステムに従って構成されている。ＦＡＴファイ
ルシステムは、今日、世界中で最も広範囲に使用されて
いるファイルシステムの１つである。テープ記憶装置の
ような周辺装置の他の形式のデータ記憶装置には、他の
ファイルシステムを接続することもできる。ファイルシ
ステムにより、オペレーティングシステムのカーネルと
デバイス従属ドライバ（ｄｅｖｉｃｅ ｄｅｐｅｎｄａ
ｎｔ ｄｅｒｉｖｅｒｓ）との間の通信を容易に行うこ
とができる。また、ファイルシステムは、オペレーティ
ングシステムのカーネルにより発せられた読取り及び書
込みコマンド（並びに、ファイルを開閉する機能）をデ
バイスドライバが認識できるフォームに変換することに
応答することができる。
処理装置と、ランダムアクセスメモリと、リードオンリ
メモリと、データ入力装置、データ出力装置、フロッピ
ディスク及び固定ディスク又はハードディスク等の種々
の不揮発性データ記憶装置等の種々の周辺装置とを有し
ている。一般に、それぞれの装置間の通信はコンピュー
タオペレーティングシステムにより制御される。良く知
られた１つのコンピュータオペレーティングシステムと
して、マイクロソフト社（Ｍｉｃｒｏｓｏｆｔ）から市
販されているＭＳ−ＤＯＳオペレーティングシステムが
ある。ＭＳ−ＤＯＳオペレーティングシステムにおいて
は、単一のファイルシステムが、周辺装置に記憶された
ファイルの編成を記載しかつ構成している。コンピュー
タシステム及びそれぞれの周辺装置の両者により認識さ
れたフォーマット中のデータをコンピュータシステムが
読み取り又は書き込みできるようにするには、データは
このファイルシステムに従って編成されなくてはならな
い。例えば、ＭＳ−ＤＯＳオペレーティングシステムに
使用される従来のフロッピディスクを用いた周辺装置に
おいては、フロッピディスクのデータは、ＦＡＴファイ
ルシステム（ファイル割当てテーブル（ｆｉｌｅ ａｌ
ｌｏｃａｔｉｏｎ ｔａｂｌｅ）を用いていることか
ら、このように命名されている）として知られているフ
ァイルシステムに従って構成されている。ＦＡＴファイ
ルシステムは、今日、世界中で最も広範囲に使用されて
いるファイルシステムの１つである。テープ記憶装置の
ような周辺装置の他の形式のデータ記憶装置には、他の
ファイルシステムを接続することもできる。ファイルシ
ステムにより、オペレーティングシステムのカーネルと
デバイス従属ドライバ（ｄｅｖｉｃｅ ｄｅｐｅｎｄａ
ｎｔ ｄｅｒｉｖｅｒｓ）との間の通信を容易に行うこ
とができる。また、ファイルシステムは、オペレーティ
ングシステムのカーネルにより発せられた読取り及び書
込みコマンド（並びに、ファイルを開閉する機能）をデ
バイスドライバが認識できるフォームに変換することに
応答することができる。
【発明が解決しようとする課題】ＭＳ−ＤＯＳオペレー
ティングシステムを用いる場合には、オペレーティング
システムは、コンピュータシステムに用いられている特
定の周辺装置に使用できる適合ファイルシステムを構成
しなければならない。一旦ファイルシステムが構成され
たならば、このファイルシステムは、オペレーティング
システムが変更されない限りそのままであり、すなわち
変更されることはない。このため、一般に、広範囲のプ
ログラム作成努力と多大の消費時間とが要求される。ま
た、コンピュータオペレーティングシステムについての
広範囲の知識が必要であり、オペレーティングシステム
の詳細にアクセスできない人は、ファイルシステムを容
易に変更することはできない。また、従来のシステムに
おいては、異種ファイルシステム（ｆｏｒｅｉｇｎｆｉ
ｌｅ ｓｙｓｔｅｍｓ）のファイルを収容しているディ
スクメディアを、固有システム（ｎａｔｉｖｅｓｙｓｔ
ｅｍ）に使用することはできない。例えば、多数の製造
業者（各製造業者は別々のファイルシステム構成に準拠
している）により多くのコンピュータシステムが多年に
亘って開発されている。現在のスタティックファイルシ
ステムの技術では、一般に、或る１つのシステムからの
ディスクメディアを別の形式のシステムで機能させるこ
とはできない。コンピュータは一層ポピュラーなものと
なっているため、あらゆる形式のコンピュータシステム
の間でファイルを共用できるようにすることの重要性が
増大している。事実上知られているあらゆるコンピュー
タシステムからのディスクメディアを、単一のオペレー
ティング環境において自動的に認識しかつ読み取ること
ができるシステムは未だ存在しない。また、コンピュー
タオペレーティングシステムのカーネルを変える必要な
くして、或るシステムに付加（又は変更）できるファイ
ルシステムは未だ存在しない。従って、本発明の目的は
現在のファイルシステムに性能が勝っている改良された
ファイルシステムを提供することである。本発明の別の
目的はディスクの崩壊を最小とするファイルシステム構
成を提供することである。本発明の更に別の目的は指定
されたボリュームにファイルを迅速且つ効率よく配置で
きるようにするファイルシステム構成を提供することで
ある。本発明のこれらの目的及び他の目的は、添付図面
を参照して以下に述べる本発明の詳細な説明により明ら
かになるであろう。
ティングシステムを用いる場合には、オペレーティング
システムは、コンピュータシステムに用いられている特
定の周辺装置に使用できる適合ファイルシステムを構成
しなければならない。一旦ファイルシステムが構成され
たならば、このファイルシステムは、オペレーティング
システムが変更されない限りそのままであり、すなわち
変更されることはない。このため、一般に、広範囲のプ
ログラム作成努力と多大の消費時間とが要求される。ま
た、コンピュータオペレーティングシステムについての
広範囲の知識が必要であり、オペレーティングシステム
の詳細にアクセスできない人は、ファイルシステムを容
易に変更することはできない。また、従来のシステムに
おいては、異種ファイルシステム（ｆｏｒｅｉｇｎｆｉ
ｌｅ ｓｙｓｔｅｍｓ）のファイルを収容しているディ
スクメディアを、固有システム（ｎａｔｉｖｅｓｙｓｔ
ｅｍ）に使用することはできない。例えば、多数の製造
業者（各製造業者は別々のファイルシステム構成に準拠
している）により多くのコンピュータシステムが多年に
亘って開発されている。現在のスタティックファイルシ
ステムの技術では、一般に、或る１つのシステムからの
ディスクメディアを別の形式のシステムで機能させるこ
とはできない。コンピュータは一層ポピュラーなものと
なっているため、あらゆる形式のコンピュータシステム
の間でファイルを共用できるようにすることの重要性が
増大している。事実上知られているあらゆるコンピュー
タシステムからのディスクメディアを、単一のオペレー
ティング環境において自動的に認識しかつ読み取ること
ができるシステムは未だ存在しない。また、コンピュー
タオペレーティングシステムのカーネルを変える必要な
くして、或るシステムに付加（又は変更）できるファイ
ルシステムは未だ存在しない。従って、本発明の目的は
現在のファイルシステムに性能が勝っている改良された
ファイルシステムを提供することである。本発明の別の
目的はディスクの崩壊を最小とするファイルシステム構
成を提供することである。本発明の更に別の目的は指定
されたボリュームにファイルを迅速且つ効率よく配置で
きるようにするファイルシステム構成を提供することで
ある。本発明のこれらの目的及び他の目的は、添付図面
を参照して以下に述べる本発明の詳細な説明により明ら
かになるであろう。
【課題を解決するための手段】要するに本発明は、第１
のディスク フィールドがブート ブロックを備え、こ
の第１のフィールドにつずく第２のフィールドがスーパ
ーブロックを備え、この第２のフィールドに続く第３の
フィールドはスペアブロックを備え、そして複数のバン
ドがデータを記憶するための一連の連続セクタを含み、
各バンドはセクタ使用を示すフリースペース ビット
マップを含んでいる、ボリュームもしくはディスク内で
データを編成する改良構造を本発明は意図している。フ
リースペース ビットマップはバンドの始めか終わりに
あって、交互のバンドのためのビットマップは相互に隣
接している。ブートブロックはボリューム ネーム、ボ
リュームＩ．Ｄ．そしてディスク ブートストラップ
プログラムを含んでいる。スーパーブロックはフリース
ペース ビットマップ、バッド ブロック リスト、デ
イクショナリ ブロックバンドそしてルート デイクシ
ョナリへのポインタを含んでいる。本発明に従ってファ
イルとデイクショナリとはＦノード構成にアンカーされ
ている。Ｆノード構成はセクタの続きを指している複数
のポインタを備えている。
のディスク フィールドがブート ブロックを備え、こ
の第１のフィールドにつずく第２のフィールドがスーパ
ーブロックを備え、この第２のフィールドに続く第３の
フィールドはスペアブロックを備え、そして複数のバン
ドがデータを記憶するための一連の連続セクタを含み、
各バンドはセクタ使用を示すフリースペース ビット
マップを含んでいる、ボリュームもしくはディスク内で
データを編成する改良構造を本発明は意図している。フ
リースペース ビットマップはバンドの始めか終わりに
あって、交互のバンドのためのビットマップは相互に隣
接している。ブートブロックはボリューム ネーム、ボ
リュームＩ．Ｄ．そしてディスク ブートストラップ
プログラムを含んでいる。スーパーブロックはフリース
ペース ビットマップ、バッド ブロック リスト、デ
イクショナリ ブロックバンドそしてルート デイクシ
ョナリへのポインタを含んでいる。本発明に従ってファ
イルとデイクショナリとはＦノード構成にアンカーされ
ている。Ｆノード構成はセクタの続きを指している複数
のポインタを備えている。
【作用】本発明の原理によれば、第１のディスク フィ
ールドがブートブロックを備え、この第１のフィールド
につづく第２のフィールドがスーパーブロックを備え、
この第２のフィールドに続く第３のフィールドはスペア
ブロックを備え、そして複数のバンドがデータを記憶す
るための一連の連続セクタを含み、各バンドはセクタ使
用を示すフリースペースビットマップを含んでいる、デ
ィスクの一連のフィールドにデータを編成する。フリー
スペースビットマップはバンドの始めか終わりにあっ
て、交互のバンドのためのビットマップは相互に隣接し
ている。ブートブロックはボリュームネーム、ボリュー
ムＩ．Ｄ．そしてディスクブートストラッププログラム
を含んでいる。スーパーブロックはフリースペースビッ
トマップ、バッドブロックリスト、ディクショナリブロ
ックバンド、そしてルートディクショナリへのポインタ
を含んでいる。
ールドがブートブロックを備え、この第１のフィールド
につづく第２のフィールドがスーパーブロックを備え、
この第２のフィールドに続く第３のフィールドはスペア
ブロックを備え、そして複数のバンドがデータを記憶す
るための一連の連続セクタを含み、各バンドはセクタ使
用を示すフリースペースビットマップを含んでいる、デ
ィスクの一連のフィールドにデータを編成する。フリー
スペースビットマップはバンドの始めか終わりにあっ
て、交互のバンドのためのビットマップは相互に隣接し
ている。ブートブロックはボリュームネーム、ボリュー
ムＩ．Ｄ．そしてディスクブートストラッププログラム
を含んでいる。スーパーブロックはフリースペースビッ
トマップ、バッドブロックリスト、ディクショナリブロ
ックバンド、そしてルートディクショナリへのポインタ
を含んでいる。
【実施例】図１及び図２には、本発明の原理に従って構
成されたコンピュータシステム１００が示されている。
このコンピュータシステム１００は、中央処理装置すな
わちマイクロプロセッサ１０２と、ランダムアクセスメ
モリ１０４と、リードオンリメモリ１０６と、マウス１
０８及びキーボード１１０のような入力装置と、ディス
プレイ１１２及びプリンタ１１４のような出力装置と、
フロッピディスクドライブ１１６、ハードディスクドラ
イブ１２０、ＣＤ−ＲＯＭドライブ１２２及びテープド
ライブ１２４等からなる種々の不揮発性記憶装置とを有
している。また、このコンピュータシステム１００は、
ネットワーク１２６と通信できるようになっている。不
揮発性記憶とは、装置の電源を遮断してもデータが消去
されないことをいう。従来のシステムにおいては、オペ
レーティングシステムは、各周辺装置が単一のメディア
形ファイルシステムドライバのみと互換性をもつファイ
ルシステムドライバによりスタティックに構成されてい
る。指定のファイルシステムドライブとの互換性のない
ドライブにメディアが供給されると、メディアは首尾良
くアクセスすることができない。以下に説明するよう
に、本発明は、周辺装置とは独立してかつメディアに関
するデータのフォーマット又は位置についての条件を賦
課することなくして、関連するファイルシステムにメデ
ィアを自動的にマッピングする方法及び手段を提供する
ものである。例えば、フロッピドライブユニット（フロ
ッピディスクドライブ）１１６は、多数のファイルシス
テムに従ってフォーマット化されたボリューム（例え
ば、ＦＡＴファイルシステムに従ってフォーマット化さ
れたボリューム１２８、良く知られたＨｉｇｈ Ｓｉｅ
ｒｒａファイルシステムに従ってフォーマット化された
ボリューム１３２、及びもう１つのファイルシステムに
従ってフォーマット化されたボリューム１３０）に使用
することができる。同様に、ハードディスク（ハードデ
ィスクドライブ）１２０の種々の区分（パーティショ
ン）は、ボリューム１３４、１３６、１３８として表し
た多数のファイルシステムに従ってフォーマット化する
ことができる。同様に、ＣＤ−ＲＯＭドライブ１２２及
びテープシステム（テープドライブ）１２４は、ボリュ
ーム１４０、１４２（これらは、それぞれのファイルシ
ステムに従ってフォーマット化されている）に使用する
ことができる。また、ネットワーク１２６は、サーバ
（該サーバは、それら自体のファイルシステムに従って
作動する）を備えた任意の数のネットワークに接続する
ことができる。コンピュータシステム１００の作動（オ
ペレーション）は、良く知られた多数のオペレーティン
グシステムのうちの任意のオペレーティングシステムに
より調整することができる。しかしながら、本発明は特
に、Ｍｉｃｒｏｓｏｆｔ社により開発されたＯＳ／２オ
ペレーティングシステムに使用するのに適している。本
発明の作動環境（ｏｐｅｒａｔｉｎｇ ｅｎｖｉｒｏｎ
ｍｅｎｔ）の構成が図２に示してある。一般に、アプリ
ケーション１５２は、カーネル１５４により処理される
ファイルシステムのリクエストを発生する。次いで、カ
ーネル１５４は、このリクエストを適当なファイルシス
テムドライバ（ＦＳＤ）１５６〜１７０に導く。任意の
ファイルシステムドライバを、多数のハードウェア装置
と協働させることができる。例えば、ボリューム１７
２、１７４についてファイルシステム作動を行う場合に
は、Ｈｉｇｈ Ｓｉｅｒｒａファイルシステム１５６を
ＣＤ−ＲＯＭプレーヤ（ＣＤ−ＲＯＭドライブ）１２２
及びディスクドライブ１１６に使用することができる。
同様に、ＦＡＴファイルシステム１６０及びＨＰＦＳフ
ァイルシステム１６２の両者は、ボリューム１７６、１
７８（これらの各々は、ハードディスク１２０にある）
についてのファイルシステム作動を行うのに使用するこ
とができる。ボリューム１８０についてファイルシステ
ム作動を行う場合には、ディスクドライブ１１６にファ
イルシステムドライバを使用することができる。従っ
て、本発明によれば、ファイルシステムの形式及びフォ
ーマットの如何に拘わらず、適当なファイルシステムに
不確実メディアを自動的にかつダイナミックにマッピン
グする方法及び手段が提供される。図３は、従来技術に
よるＭＳ−ＤＯＳオペレーティングシステムのファイル
システム構成を示すものである。ＭＳ−ＤＯＳオペレー
ティングシステム２００においては、オペレーティング
システムのカーネル２０４内にＦＡＴファイルシステム
２０２が埋設されている。このＦＡＴファイルシステム
２０２はオペレーティングシステムのカーネル２０４内
に一体化されているため、変更（モディファイ）するこ
とは困難である。また、付加的なファイルシステムが必
要な場合には、オペレーティングシステムのカーネル２
０４を書き替えてそれらのファイルシステムに適合でき
るようにしなければならない。本発明によれば、図４に
示すシステム技術により上記問題点を解決することがで
きる。本発明のコンピュータシステム１００において
も、ＯＳ／２カーネル２５２内には、ＦＡＴファイルシ
ステム２０２が埋設されている。しかしながら、本発明
によれば、オペレーティングシステムのカーネル２５２
に対して外部装置であるＦＡＴファイルシステムドライ
バ２５４、２５６、２５８をダイナミックに取り付ける
方法及び手段が提供される。図面には、設置可能な３つ
のファイルシステムドライバを備えたシステム２５０が
示されているが、実際には、本発明は、ファイルシステ
ムドライバの数に制限されることはない。設置可能（ｉ
ｎｓｔａｌｌａｂｌｅ）なファイルシステムドライバ
（ｆｉｌｅｓｙｓｔｅｍ ｄｒｉｖｅｒ、「ＦＳＤ」）
は、多くの点でデバイスドライバに類似している。ＦＳ
Ｄは、ダイナミックリンクライブラリ（ｄｙｎａｍｉｃ
−ｌｉｎｋ ｌｉｂｒａｒｙ、「ＤＬＬ」、一般には、
ＳＹＳ又はＩＦＳエクステンションを備えている））の
ように構成されたファイルのディスク上に存在し、ＣＯ
ＮＦＩＧ．ＳＹＳファイルにおけるＩＦＳ＝ステートメ
ント（ｓｔａｔｅｍｅｎｔｓ）によるシステムの初期化
中にローディングされる。ＩＦＳ＝宣言（ｄｉｒｅｃｔ
ｉｖｅｓ）は、それらが出合う命令において処理され、
また、デバイスドライバについてＤＥＶＩＣＥ＝文（ｓ
ｔａｔｅｍｅｎｔｓ）の命令に対して感応する。これに
より、ユーザが、非標準デバイス用のデバイスドライバ
をローディングし、該デバイスのボリュームからファイ
ルシステムドライバをローディングすること等が可能に
なる。一旦ＦＳＤが設置され且つ初期化されると、カー
ネルは、ファイルの開放、読取り、書込み、シーク（ｓ
ｅｅｋｓ）、閉鎖等についての論理的リクエスト（ｌｏ
ｇｉｃａｌ ｒｅｑｕｅｓｔ）の言語で、ＦＳＤで通信
する。ＦＳＤは、ボリュームそれ自体に見出される制御
構成及びテーブルを用いて、これらのリクエストをセク
タ読取り（ｓｅｃｔｏｒ ｒｅａｄｓ）用のリクエスト
に翻訳し、かつ、ファイルシステムヘルパ（Ｆｉｌｅ
Ｓｙｓｔｅｍ Ｈｅｌｐｅｒｓ、「ＦｓＨｌｐｓ」）と
呼ばれる特別なカーネル入口点を呼び出すことができる
書込みを行う。カーネルは、セクタＩ／Ｏに対するデマ
ンドを適当なデバイスドライバに導き、かつその結果を
ＦＳＤに戻す。ボリュームをＦＳＤｓ（複数のＦＳＤ）
と結合させるべくオペレーティングシステムにより用い
られる手順は、ダイナミックボリュームマウンティング
（ｄａｙｎａｍｉｃ ｖｏｌｕｍｅ ｍｏｕｎｔｉｎ
ｇ）と呼ばれ、次のように作動する。ボリュームが最初
にアクセスされるとき、或いは、直接アクセスを行うべ
く（例えばＦＯＲＭＡＴオペレーションにより）ボリュ
ームがロックされ次いでアンロックされた後に、オペレ
ーティングシステムのカーネルは、ボリュームからＦＳ
Ｄｓの各々への識別情報を発生し、これは、ＦＳＤがこ
の情報を認識するまで順次行われる。ＦＳＤがボリュー
ムをクレイムすると、ボリュームがマウントされ、ボリ
ュームに対する全ての連続ファイルＩ／Ｏリクエスト
が、ボリュームをクレイムしたＦＳＤに導かれる。この
構成により、従来技術にはない幾つかの利点を得ること
ができる。例えば、不確実メディアがコンピュータシス
テムに与えられる場合に、コンピュータシステムは、利
用できるファイルシステムドライバを走査して、このメ
ディアを認識できるファイルシステムドライバを位置付
けすることができ、これにより、メディアへのファイル
システムドライバの自動マッピングを行うことが可能に
なる。また、オペレーティングシステムのカーネルを変
更する必要なくして、ファイルシステムドライバを更新
することができる。更に、新しい形式の周辺装置が開発
されたときに、既存システムのソフトウェアを混乱させ
ることなく、適当なファイルシステムドライバをオペレ
ーティングシステムに付加することができる。コンピュ
ータシステム１００のより詳細なダイアグラムが図５に
示してある。コンピュータシステム１００は、アプリケ
ーションプログラム３０２とディスク装置３０４のよう
なデータ記憶装置との間の通信を行うことができるオペ
レーティングシステムのカーネル２５２を有している。
また、このコンピュータシステム１００は、ファイルシ
ステムドライバ２５４〜２５８と関連して作動するデバ
イスドライバ３０６を有している。図面には単一の周辺
装置３０４を備えたコンピュータシステム１００が示さ
れているが、本発明は、任意の数の論理的又は物理的周
辺装置と組み合わせて使用できるものである。作動に際
し、アプリケーションプログラム３０２は、所望の機能
についての入口点を呼び出すことにより、オペレーティ
ングシステムのカーネル２５２に対する論理的ファイル
リクエストを発行する。これらの機能には、ファイルを
開放すること（ＤｏｓＯｐｅｎ）、ファイルを読み取る
こと（ＤｏｓＲｅａｄ）、ファイルに書き込むこと（Ｄ
ｏｓＷｒｉｔｅ）等のリクエストを含めることができ
る。オペレーティングシステムのカーネル２５２は、こ
れらのリクエストを、ファイルを保持（ホールディン
グ）する特定のボリュームについての適当なファイルシ
ステムドライバ２５４〜２５８に導く。次に、適当な設
置可能なファイルシステムドライバが、論理的ファイル
リクエストを、指定メディアの論理的セクタの読取り及
び書込みのためのリクエストに翻訳し、かつオペレーテ
ィングシステムのカーネルのファイルシステムヘルパ３
０８を呼び出して、これらのリクエストを適当なデバイ
スドライバ３０６に導く。ファイルシステムヘルパ（Ｆ
ｓＨｌｐｓ）３０８については、以下により詳細に説明
する。デバイスドライバ３０６は、オペレーティングシ
ステムのカーネルからの論理的セクタリクエストを、特
定の物理ユニット（すなわち、メディアのシリンダ、ヘ
ッド及びセクタ）についてのリクエストに変形し、か
つ、ディスク装置にコマンドを発行して、ディスクメデ
ィアとランダムアクセスメモリ３１０との間にデータを
伝達する。次に、物理装置を特定のファイルシステムに
マッピングすることについて以下に詳細に説明する。Ｍ
Ｓ−ＤＯＳ環境（ＭＳ−ＤＯＳ ｅｎｖｉｒｏｎｍｅｎ
ｔ）においては、フロッピディスクはボリュームと呼ば
れる。固定ディスク（又はハードディスク）は、多数の
ボリュームに区分することができる。このターミノロジ
が、本発明に首尾よく適用されている。簡単に言えば、
コンピュータシステムが最初にブート（ｂｏｏｔ）され
るとき、ボリュームが最初にアクセスされるとき、又は
コンピュータシステムが、ディスク装置３０４内に不確
実メディアが存在することを決定するときにはいつで
も、コンピュータシステムは、ファイルシステムドライ
バのリンクされたリストにおける最初のファイルシステ
ムドライバを試験する。ファイルシステムドライバがデ
ィスク装置にローディングされたボリュームを認識する
場合には、ファイルシステムドライバがマウントされ
る。そうでない場合には、コンピュータシステムは、メ
ディアを認識するファイルシステムドライバが位置付け
されるまで、利用できるファイルシステムドライバを連
続的にボーリングする。関心をもつメディアを認識する
設置可能なファイルシステムドライバが全く見出されな
い場合には、省略時ファイルシステムドライバがマウン
トされる。本発明の好ましい実施例においては、省略時
ファイルシステムは、上記のＦＡＴファイルシステムで
ある。不確実メディアは、幾つかの方法により検出する
ことができる。ディスク装置には機械的なラッチ機構が
設けられており、該ラッチ機構は、ディスクがディスク
装置から取り出されるとき又はディスク装置に装填され
るときに作動する。一般にラッチ機構は、ドライブの次
の作動によりドアが開放されたことを示すように機能す
る。デバイスドライバがこの表示を受け取ると、エラー
不確実メディア（ＥＲＲＯＲ＿ＵＮＣＥＲＴＡＩＮ Ｍ
ＥＤＩＡ）がオペレーティングシステムに戻される。機
械的なラッチ機構がないシステムにおいては、所定時間
より短い時間内にメディアを変更できないと考えられ
る。本発明の好ましい実施例においては、この時間は２
秒であるこ考えられる。従って、所定時間以上の時間を
かけても特定のボリュームがアクセスされない場合に
は、このメディアは不確実であると推定される。図６
は、ＦＡＴファイルシステムのディスクフォーマットの
ダイアグラムである。ＦＡＴファイルシステムは、ＭＳ
−ＤＯＳオペレーティングシステムの初期から該ＭＳ−
ＤＯＳオペレーティングシステムに使用されている。Ｆ
ＡＴファイルシステムについての詳細な説明が、Ｄａｎ
ｃａｎ著「アドバンスＭＳ ＤＯＳプログラミング
（“Ａｄｖａｎｃｅ ＭＳ ＤＯＳ Ｐｒｏｇｒａｍｍ
ｉｎｇ”）」（Ｍｉｃｒｏｓｏｆｔ Ｐｒｅｓｓ社刊、
１９８６、１９８８）においてなされている。ＦＡＴフ
ァイルシステムは、ＦＡＴファイルシステムは、ファイ
ル割当てテーブル（Ｆｉｌｅ Ａｌｌｏｃａｔｉｏｎ
Ｔａｂｌｅ）を中心題目としている。各論理的ボリュー
ムはそれ自体のＦＡＴと関連していて、２つの重要な機
能を有している。すなわち、各論理的ボリュームは、割
当てユニット（ａｌｌｏｃａｔｉｏｎｕｎｉｔｓ）のリ
ンクされたリストの形態をなすボリュームに関する各フ
ァイルについての割当て情報（ａｌｌｏｃａｔｉｏｎ
ｉｎｆｏｒｍａｔｉｏｎ）を収容していて、その割当て
ユニットには、創出（又は拡大）されているファイルへ
の割当て（代入、ａｓｓｉｇｎｍｅｎｔ）がないことを
表示する。ＦＡＴファイルシステムに従ってディスクが
フォーマット化されると、ブートセクタ（ｂｏｏｔ ｓ
ｅｃｔｅｒ）がセクタゼロと書き込まれる。ファイル割
当てテーブルの後にはルートディレクトリ（ｒｏｏｔ
ｄｉｒｅｃｔｏｒｙ）が続き、このルートディレクトリ
の後にはボリュームファイルが続く。ブートセクタに
は、ブートパラメータブロックすなわちＢＰＢと呼ばれ
る、或る領域におけるボリュームに関する種々の記述情
報（ｄｅｓｃｒｉｐｔｉｖｅ ｉｎｆｏｒｍａｔｉｏ
ｎ）、ドライブの数及びボリュームＩ．Ｄ．のような情
報、及びブートストラップルーチン（ｂｏｏｔｓｔｒａ
ｐ ｒｏｕｔｉｎｅ）が収容されている。ファイル割当
てテーブルは、ディスクについての割当て可能なクラス
タ（これらのクラスタは、セクタを２乗したものであ
る）に直接相当するフィールド（欄）に区分される。一
般に、これらのフィールドは１６ビットの幅を有してい
る。最初にリザーブされたＦＡＴ入口には、ＢＰＢにお
いても見出すことができるメディア記述バイト（ｍｅｄ
ｉａ ｄｅｓｃｒｉｐｔｏｒ ｂｙｔｅ）のコピーが収
容されている。リザーブされた残余のフィールドにはＯ
ＦＰＨが収容されている。残余のＦＡＴ入口には、それ
らの相当ディスククラスタ（ｃｏｒｒｅｓｐｏｎｄｉｎ
ｇ ｄｉｓｋ ｃｌｕｓｔｅｒｓ）の使用が記述され
る。ディレクトリの各ファイルの入口には、これらのフ
ァイル（該ファイルは、ＦＡＴへの入口点として使用さ
れる）に割り当てられる最初のクラスタの数が収容され
る。入口点から、各ＦＡＴスロット（ＦＡＴ ｓｌｏ
ｔ）が、最終クラスタマークに出合うまで、ファイル内
の次のクラスタの番号を収容する。また、ＦＡＴファイ
ルシステムには、読取りエラー等によるＦＡＴのセクタ
へのアクセスが失敗した場合に用いることができる最初
のファイル割当てテーブルの複製を維持する機能をオプ
ションとして設けることができる。ファイル割当てテー
ブルの後には、ルートディフレクトリが続く。このルー
トディレクトリは、ファイル、他のディレクトリ、及び
オプションとしてのボリュームラベルを記述する３２バ
イトの入口を収容している。ルートディレクトリの後の
残余のボリュームは、クラスタのプールとして見ること
ができるファイル領域（各ファイル領域には１つ以上の
論理的セクタが収容されている）として知られている。
各クラスタは、ＦＡＴの対応入口（該入口には、ＦＡＴ
の現在使用、すなわち、利用できること、リザーブされ
ていること、ファイルに割り当てられていること、又は
使用できないことが記述されている）を備えている。Ｆ
ＡＴファイルシステムは、１Ｍｂ以下のボリュームで優
れた性能を得ることができる。しかしながら、ボリュー
ムのサイズが１Ｍｂを越えると、ＦＡＴファイルシステ
ムの性能は急激に低下する。容易に入手可能なハードデ
ィスクのサイズは急激に増大しているため、このことは
重要な問題となっている。ボリュームが１Ｍｂ以下の場
合には、ＦＡＴは、いつでもランダムアクセスメモリ内
に保持される程充分に小さく、従って、ファイルのいか
なる部分にも非常に高速のランダムアクセスを行うこと
ができる。しかしながら、ハードディスク又は固定ディ
スクに適用した場合には、ＦＡＴは大き過ぎてメモリに
保持できなくなり、かつ細分してメモリ内にページ付け
しなければならない。このために多くの余分のディスク
ヘッド運動が必要になり、コンピュータシステムのスル
ープットを低下させている。また、ディスクの空きスペ
ース（ｆｒｅｅ ｓｐａｃｅ）についての情報が、ＦＡ
Ｔの多数のセクタを横切って分散されるため、連続的に
ファイルスペースを割り当てることは実際的でない。こ
のため：ファイルが細分化され、コンピュータシステム
のスループットが更に低下される。また、ハードディス
クに比較的大型のクラスタを用いるため、無駄なスペー
スが非常に大きくなる。図７〜図１４には、設置可能な
ファイルシステムの１つの場合のディスクフォーマット
を示す一連のダイアグラムが示されている。このファイ
ルシステムは、高性能ファイルシステム（Ｈｉｇｈ ｐ
ｅｒｆｏｒｍａｎｃｅ ｆｉｌｅ ｓｙｓｔｅｍ，ＨＰ
ＦＳ）と呼ばれているものである。本発明の高性能ファ
イルシステムは、ＦＡＴファイルシステムについての上
記問題を解消でき、かつあらゆる形式のディスクメディ
アについて優れた性能を発揮できるものである。図７に
示すように、ＨＰＦＳボリュームは、前に形成されたＦ
ＡＴパーティション形の側面に沿って固定ディスク上に
設けることができる。ＨＰＦＳボリュームは、５１２バ
イトのセクタサイズを使用しており、２１９９Ｇｂ（２
３２のセクタ）の最大サイズを有している。ＨＰＦＳは
固定ディスクに使用することを主として設計されている
が、実際上、あらゆる形式のディスクメディアとの互換
性を有している。ＨＰＦＳボリュームは、固定された構
成が殆ど必要とされない。ブートブロック５０２にはボ
リューム（８Ｋｂ）のセクタ０〜１５が割り当てられ、
該セクタ０〜１５は、ボリュームのネームフィールド
（名前欄）５０４、３２ビットボリュームの１Ｄフィー
ルド５０６、ＢＩＯＳパラメータブロック５０８、ディ
スクブートストラッププログラム５１０を収容してい
る。ディスクブートストラッププログラム５１０は、オ
ペレーティングシステムファイルが見出される限りは、
これらのオペレーティングシステムファイルの位置付け
及び読取りを行う限定モードで使用することができる。
ブートブロック（ＢｏｏｔＢｌｏｃｋ）５０２の後に
は、スーパーブロック（ＳｕｐｅｒＢｌｏｃｋ）５１２
及びスペアブロック（ＳｐａｒｅＢｌｏｃｋ）５１４が
続いている。スーパーブロック５１２は、ディスクメイ
ンテナンスユーティリティによって変更されるに過ぎな
い。スーパーブロック５１２は、空きスペースのビット
マップを指すポインタ５１６、バットブロックリスト５
１８、ディレクトリブロックバンドを指すポインタ５２
０、ルートディレクトリを指すポインタ５２２を収容し
ている。更にスーパーブロック５１２は、デート（日付
け）を備えたデートフィールド（日付け欄）５２４を収
容しており、ボリュームはＣＨＫＤＳＫにより最終チェ
ック及び修復がなされる。ＣＨＫＤＳＫは、ディスクの
悪い部分を検出しかつカタログするための良く知られた
ＯＳ／２ディスクユーティリティである。スペアブロッ
ク５１４は種々のフラグ及びポインタを収容しており、
これらについては以下に詳述する。スペアブロック５１
４は、コンピュータシステムが実行されるときに変更さ
れる。残余のボリュームは、ファイルの記憶に使用され
る８Ｍｂバンド（例えば、バンド５１６〜５２２）に区
分される。図７には４つの８Ｍｂバンドが示されている
が、ＨＰＦＳは非常に多数のバンドを得ることがきる。
各バンドには、それ自体の空きスペースビットマップ
（例えば、ビットマップ５２４〜５３４参照）が設けら
れている。空きスペースビットマップの各ビットは、セ
クタを表している。セクタが使用されている場合にはビ
ットは０であり、セクタが使用可能（アベイラブル）で
あるときには、ビットは１である。ビットマップは、バ
ンドのヘッド又はテールに位置付けされるため、２つの
ビットマップは交互のバンドの間に隣接している。ビッ
トマップのバンドサイズは、任意のサイズのファイルを
収容できるように変更できるけれども、上記構成によ
り、１６Ｍｂになるようにファイルに割り当てることが
できる最大の連続空きスペースを得ることができる。デ
ィスクのシークセンタにおいて（又はシークセンタに向
かって）位置付けされた１つのバンドは、ディレクトリ
ブロックバンドと呼ばれ、後述するような特別な処理を
受ける。ＨＰＦＳの全てのファイル又はディレクトリ
は、図８及び図９に示すＦｎｏｄｅと呼ばれている基本
ファイルシステムの目的（オブジェクト）にアンカーさ
れている。Ｆｎｏｄｅ５３０は、ファイル又はディレク
トリに割り当てられた最初のセクタすなわち第１セクタ
であり、スーパーブロック５０４におけるフィールド５
２２により指示されている。各Ｆｎｏｄｅ５３０は単一
のセクタを占拠し、かつ、図８に示すように、ファイル
システムにより内的に用いられる制御及びアクセス情報
フィールド５４０、拡大属性（ｅｘｔｅｎｄｅｄ ａｔ
ｔｒｉｂｕｔｅ、「ＥＡ」）、及びアクセス制御リスト
（ａｃｃｅｓｓ ｃｏｎｔｒｏｌ ｌｉｓｔｓ，「ＡＣ
Ｌｓ」）を記憶する領域５４２、関連するファイル又は
ディレクトリのネームの長さ及び最初の１５文字を表示
したい場合にはそのためのフィールド５４４、及び割当
て構成５４６を収容している。Ｆｎｏｄｅは、これを代
表するファイル又はディレクトリの近くに常に記憶され
ている。図９に示す割当て構成５４６は、ファイル又は
ディレクトリの連続性のサイズ及び度合に基づいて幾つ
かの形態をとる。本発明のＨＰＦＳは、１つ以上の連続
セクタの１つ以上の実行（ｒｕｎｓ）又はエクステント
の割当てとして、ファイルをビュー（ｖｉｅｗｓ）して
いる。各実行は、１対の二重ワード、すなわち、セクタ
における３２ビットのスタートセクタ数及び３２ビット
の長さ（この長さは、実行長さエンコーディングと呼ば
れている）により記号化される。アプリケーションプロ
グラムの観点からすると、エクステントは目で見ること
はできない。すなわち、ファイルはバイトの継ぎ目のな
い流れであると考えることができる。Ｆｎｏｄｅにおけ
る割当て情報にリザーブされたスペースは、各１６Ｍｂ
までのセクタの８回の実行と同数のポインタを保持する
ことができる。従って、高度連続サイズのかなり小さな
ファイルを、Ｆｎｏｄｅの中に完全に記述することがで
きる。ＨＰＦＳは、Ｆｎｏｄｅにとっては大き過ぎるか
細分され過ぎているファイルの位置を示す新しい方法を
採用しており、８回以上の実行を有している、Ｆｎｏｄ
ｅの割当ては、割当てセクタのＢ＋ツリー（木）のルー
ト（根）となり、このルートには、図１０に示すよう
に、ファイルのセクタ実行を指す実際のポインタが収容
されている。Ｂ＋ツリー及びＢ−ツリーの概念について
は後で詳述する。Ｆｎｏｄｅのルートは、１２のエレメ
ントのためのルームを有している。各割当てセクタは、
種々のセクタ情報に加えて、セクタ実行を指す４０個程
のポインタを収容することができる。従って、本発明の
好ましい実施例においては、２レベル割当てのＢ＋ツリ
ー（ｔｗｏ ｌｅｖｅｌ ａｌｌｏｃａｔｉｏｎｓ Ｂ
＋Ｔｒｅｅ）が、７．６８Ｇｂ（１２＊４０＊１６Ｍ
ｂ）の論理的最大サイズを持つ４８０（１２＊４０）回
のセクタ実行のファイルを記述することができる。これ
と異なり、高度に細分化されたファイルを記述するには
２レベル割当てのＢ＋ツリーが充分でない場合には、Ｈ
ＰＦＳファイルシステムが、ツリーに必要なだけの付加
的レベルを導入する。中間レベルにおける割当てセクタ
は、６０個程の内部（端部ではない）Ｂ＋ツリーノード
を保持することができ、このことは、この構成の記述能
力が極めて大きな数に急速に成長することを意味してい
る。例えば、３レベル割当てＢ＋ツリーは、２８，８０
０（１２＊６０＊４０）回のセクタ実行を記述すること
ができる。割当てセクタの実行長さエンコーディング
（ｒｕｎ−ｌｅｎｇｔｈ ｅｎｃｏｄｉｎｇｓ）及びＢ
＋ツリーは、ファイルのサイズ及び位置を充分に特定で
きるメモリであり、かつ従来技術に比べ幾つかの優れた
長所を有している。セクタ数への論理的ファイルオフセ
ットの翻訳は極めて高速に行われる。すなわち、ファイ
ルシステムは、正しい範囲が見出されるまで実行サイズ
を要約し、実行ポインタ（ｒｕｎ ｐｏｉｎｔｅｒｓ）
のリスト（すなわちリストのＢ＋ツリー）を単に横切る
だけである。そのとき、簡単な計算を行うことにより、
実行の中でセクタを識別することができる。また、新た
に割り当てられたセクタがファイルの前の最終セクタと
連続している場合には、実行長さエンコーディングによ
って、ファイルを論理的に拡大することが極めて簡単に
なる。このファイルシステムは、ファイルの最終実行ポ
インタのサイズ二重ワード（ｓｉｚｅ ｄｏｕｂｌｅ
ｎｏｒｄ）を単に増大させるだけであり、適当な空きス
ペースのビットマップにおけるセクタのビットをクリア
するように構成されている。ファイルと同様に、ディレ
クトリはＦｎｏｄｅｓにアンカーされる。ルートディレ
クトリ（ｒｏｏｔ ｄｉｒｅｃｔｏｒｙ）についてのＦ
ｎｏｄｅを指すポインタは、スーパーブロック５１２に
おいて見出すことができる。図１１は、本発明によるデ
ィレクトリ構成を示すものであり、ここにはディレクト
リＦｎｏｄｅ５５０が示されている。ルート以外のディ
レクトリについてのＦｎｏｄｅは、それらの親ディレク
トリ（ｐａｒｅｎｔ ｄｉｒｅｃｔｏｒｉｅｓ）におけ
るサブディレクトリ入口を通って到達する。ディレクト
リは、ディスク上に４つの連続セクタ（ｃｏｎｓｅｃｕ
ｔｉｖｅｓｅｃｔｏｒｓ）として割り当てられる２Ｋｂ
のディレクトリブロックから構成されていて、任意のサ
イズに成長することができる。例えば、ディレクトリブ
ロック５５２、５５４、５５６を参照されたい。このフ
ァイルシステムは、ディスクのシークセンタ又はその近
くに位置付けされたディレクトリバンドにディレクトリ
ブロックを割り当てることを試みている。ディレクトリ
バンドが満たされると、スペースが利用できる限り、デ
ィレクトリブロックが割り当てられる。２Ｋｂの各ディ
レクトリブロックには、１つから多数のディレクトリ入
口を設けることができる。例えば、入口５５８〜５６８
を参照されたい。ディレクトリ入口には幾つかのフィー
ルド（欄）が設けられ、これらのフィールドには、図１
１に示すように、時間及び日付スタンプのためのフィー
ルド５７０と、Ｆｎｏｄｅポインタを収容するフィール
ド５７２と、ディスクメインテナンスプログラム（この
プログラムは良く知られたものである）による使用がで
きるようにするための用法カウントフィールド（ｕｓａ
ｇｅ ｃｏｕｎｔ ｆｉｅｌｄ）５７４と、ファイルの
長さすなわちディレクトリネームを収容するフィールド
５７６と、ネーム自体のフィールド５７８と、Ｂ−ツリ
ーポインタを収容するフィールド５８０とが含まれてい
る。各ディレクトリ入口は、入口の長さを含んでいるワ
ード５８２で始まる。これにより、各入口の終時におけ
るフレックススペースの可変量が与えられる。この可変
量は、ファイルシステムの特別なバージョンに使用でき
るようにし、かつディレクトリブロックを極めて迅速に
横切らせることを可能にする。ディレクトリブロックの
入口の数は、ネームの長さによって変化する。平均的な
ファイルネームの長さが１３文字であるときには、平均
ディレクトリブロックはほぼ４０個の入口を保持するで
あろう。ディレクトリブロックの入口は、それらのネー
ムフィールド（名前欄）の２進字句順序（ｂｉｎａｒｙ
ｌｅｘｉｃａｌ ｏｒｄｅｒ）により分類される。最
終入口は、ブロックの終了を印すダミーレコードであ
る。ディレクトリが大きくなり過ぎて１つのブロック内
に記憶されなくなった場合には、Ｂ−ツリーとして編成
される２Ｋｂブロックを付加することによりサイズを大
きくできる。特定のネームをサーチする場合には、ファ
イルシステムが一致を見出すか、目的とするネームより
も字句的に多いネームを見出すまで、ファイルシステム
がディレクトリブロックを横行する。後者の場合、ファ
イルシステムが、入口からＢ−ツリーのポインタを抽出
する。このポインタがどのサーチフィールドをも指示し
ない場合には、ファイルシステムは、ツリーにおける次
のディレクトリブロックを次のポインタにより指示さ
せ、サーチを続行する。ブロック当り４０個の入口があ
るものと仮定すれば、ディレクトリブロックの２レベル
ツリーは１，６４０個のディレクトリ入口を保持でき、
３レベルツリーは６５，６４０個の入口を保持すること
ができる。換言すれば、最大限３つのディスクアクセス
を備えた一般的な６５，６４０個のファイルにおいて、
特定のファイルを見出すことができる（又は、それが存
在しないことを示すことができる）。ディスクアクセス
の実際の数は、キャッシュコンテンツ（ｃａｃｈｅ ｃ
ｏｎｔｅｎｔｓ）及びディレクトリブロックのＢ−ツリ
ーのファイルネームの位置に基づいて定められる。これ
は、最悪の場合４，０００個のセクタを読み取って、同
数のファイルを収容しているディレクトリにファイルが
存在するか否かを画定しなければならないＦＡＴファイ
ルシステムに対して顕著な改善を与えるものである。Ｈ
ＰＦＳのＢ−ツリーディレクトリ構成は、開放作業及び
見出し作業に関するその効果を超える興味ある含意（ｉ
ｍｐｌｉｃａｔｉｏｎｓ）を有している。ディレクトリ
ブロックを付加（又は除去）するか、或いはネームが或
るブロックから他のブロックに移動されてツリーのバラ
ンスを保つとき、ファイルの創出、リネーミング又は削
除により、複雑な作業のカスケードを生じさせるかもし
れない。実際、ファイル自体が成長することはないけれ
ども、リネーム作業によってディスクスペースの不足を
きたすであろう。この問題を回避するには、ＨＰＦＳ
が、ディレクトリの緊急時に引き出すことができる空き
ブロックの小さなプールをリザーブし、このプールを指
すポインタがスペアブロックに記憶されるように構成す
るのが好ましい。ファイル属性は、ファイルの明白な記
憶領域の外でオペレーティングシステムにより維持され
るファイルについての情報である。本発明のＨＰＦＳ
は、拡大属性（Ｅｘｔｅｎｄｅｄ Ａｔｔｒｉｂｕｔｅ
ｓ，「ＥＡｓ」を支持し、ネームバリューの形態をと
る。但し、バリュー部分は、ゼロで終わる記号列（ｎｕ
ｌｌ−ｔｅｒｍｉｎａｔｅｄｓｔｒｉｎｇ，「ＡＳＣＩ
ＩＺ」）でもよいし２進データでもよい点を除く。本発
明の好ましい実施例においては、各ファイル又はディレ
クトリは、これに取り付けられたＥＡｓの６４Ｋｂの最
大値をとることができる。但し、この制限は容易に変更
することができる。ＥＡｓの記憶方法は変えることがで
きる。所与のファイル又はディレクトリと関連するＥＡ
ｓが充分に小さい場合には、これらのＥＡｓはＦｎｏｄ
ｅに記憶されるであろう。また、ＥＡｓの全体のサイズ
が非常に大きいときには、これらのＥＡｓはセクタ実行
においてＦｎｏｄｅｓの外に記憶され、割当てセクタの
Ｂ＋ツリーが創出されて実行が記述される。単一のＥＡ
が非常に大きい場合には、該ＥＡはＦｎｏｄｅの外に押
し出され、該ＥＡ自体のＢ＋ツリー内に押し込まれる。
本発明は、アプリケーションプログラムがファイルの拡
大属性（ＥｘｔｅｎｄｅｄＡｔｔｒｉｂｕｔｅｓ）を走
査することを可能にするＯＳ／２カーネルのＡＰＩ機
能、すなわち、ＤＯＳＱＦｉｌｅＩｎｆｏ及びＤｏｓＳ
ｅｔＦｉｌｅＩｎｆｏを改善することができる。また、
本発明によれば、任意のパスネーム（パス名）と関連す
るＥＡｓの読取り及び書込みに使用できる２つの新たな
機能、すなわちＤＯＳＱＰａｔｈＩｎｆｏ及びＤＯｓＳ
ｅｌＰａｔｈＩｎｆｏを得ることができる。アプリケー
ションプログラムは、特定のＥＡ（これは、一致させる
べきネームを供給する）のバリューを要求するか、ファ
イル又はディレクトリについての全てのＥＡｓを一度に
得ることができる。ＥＡｓの支持により、目的にかなっ
たアプリケーションプログラムの使用が容易になる。フ
ァイルを所有するアプリケーションのネームから、従属
ファイルのネーム、アイコン及び実行コード（ｅｘｅｃ
ｕｔａｂｌｅ ｃｏｄｅ）に至る殆ど全ての形式の情報
をＥＡｓに記憶させることができる。ＨＰＦＳは、多レ
ベルでのディスクスループットの潜在的ボトルネックを
アタックする。性能を向上させるため、ＨＰＦＳは、進
歩したデータ構成、連続セクタ割当て、インテリジェン
トキャッシング、読取りヘッド、及びデファード書込み
（ｄｅｆｅｒｒｅｄ ｗｒｉｔｅｓ）を使用している。
最初に、ＨＰＦＳは、そのデータ構成、すなわち、ファ
イルネーム、ディレクトリネーム、ファイル又はディレ
クトリに割り当てられたセクタのリストへの高速ランダ
ムアクセスが行えるようにした複雑なデータ構成（Ｂ−
ツリー及びＢ＋ツリー）、及び適当なサイズの空きスペ
ースのチャンクを位置付けできるようにする簡単でコン
パクトなデータ構成（ビットマップ）をタスクに一致さ
せる。これらのデータ構成を操作するルーチンは、アセ
ンブラ言語で記載するのが好ましい。ＨＰＦＳの主目的
は、可能な限り、連続セクタをファイルに割り当てるこ
とである。ディスクの読取り／書込みヘッドを或るトラ
ックから他のトラックに移動させるのに要する時間は、
可能性のある他の遅延よりも遙かに重大であり、このた
め、ＨＰＦＳは、ファイルスペースを連続的に割り当て
ることにより、及びＦｎｏｄｅ及び該Ｆｎｏｄｅが制御
する事柄の近くの空きスペースビットマップのような制
御構成を維持することにより、このようなヘッド運動を
回避するか最小限にする。高度の連続的なファイルはま
た、多くのセクタに対し一度に要求されるディスクドラ
イバのリクエストを、ファイルシステムによって少なく
することを補助し、ディスクドライバが、ディスクコン
トローラの多セクタ移送能力を活用できるようにし、か
つ、修理すべきディスクの完全な中断数を低減させるこ
とができる。多数のファイルを同時に更新させるマルチ
タスキングオペレーティングシステムにおいてファイル
が細分化されないように維持することは、従来技術には
見られない特徴である。ＨＰＦＳが用いている１つの方
法（手順）は、新しく創出されたファイルを別々のバン
ドのディスクを横切って分散させ、できるならば、セク
タが拡大されるときファイルに割り当てられるセクタが
インターリーブされないようにすることである。他の方
法は、ファイルを拡大しなければならない度毎に、連続
スペースの４Ｋｂをファイルに予め割り当てて、ファイ
ルを閉じるときに全ての過剰のスペースを戻す方法であ
る。アプリケーションが、新しいファイルの最終的サイ
ズを予め知ることができるならば、ＨＰＦＳがファイル
を創出するときに、最初のファイル割当てを特定化する
ことにより、ＨＰＦＳを補助することができるであろ
う。そうすれば、システムは全ての空きスペースビット
マップをサーチして、ファイルを充分に保持できる連続
セクタの実行を見出すことができるであろう。このこと
に失敗した場合には、システムは、ファイルのサイズの
１／２である２ラウンドをサーチし、以下このことが繰
り返される。ＨＰＦＳは、幾つかの異なる種類のキャッ
シングに頼って、ＨＰＦＳが要求する物理ディスク転送
の数を最小限にしている。ＨＰＦＳは、ＦＡＴファイル
システムが行ったようにして、セクタのキャッシングを
行う。しかしながら、ＦＡＴファイルシステムとは異な
り、ＨＰＦＳは非常に大きなキャッシユを効率良く管理
し、セクタキャッシングを、パーハンドルベース（ｐｅ
ｒ−ｈａｎｄｌｅ ｂａｓｉｓ）で、ファイルが用いら
れる方法に調節するようになっている。また、ＨＰＦＳ
は、パスネーム、ディレクトリ、トランスフォーミング
ディスクディレクトリ入口を、記憶表現（ｍｅｍｏｒｙ
ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）におけるよりコンパ
クトで効率の良いものにキャッシングする。性能を向上
させるべくＨＰＦＳが用いられているもう１つの技術
は、プログラムが必要とすると考えられるデータを予め
読み取ることである。例えば、ファイルが開かれると
き、ファイルシステムが、Ｆｎｏｄｅ及びファイルの内
容の最初の幾つかのセクタを予めよみとりかつキャッシ
ングする。ファイルが、該ファイル注の実行プログラム
（Ｅｘｅｃｕｔａｂｌｅ Ｐｒｏｇｒａｍ）又はヒスト
リー情報である場合には、Ｆｎｏｄｅは、全ファイルを
直ちに連続的に読み取ることにより、ファイルの開放作
業が一般的に続けられていることを示す。ファイルシス
テムは、より多くのファイル内容物を用意しかつキャッ
シングする。プログラムが比較的少量の読取りリクエス
トを発行する場合には、ファイルシステムは２Ｋｂのチ
ャングのファイルから絶えずデータを取り出し、過剰の
データをキャッシングする。このキャッシングにより、
殆どの読取り作業が満足できるものになる。本発明のＨ
ＰＦＳは、ＯＳ／２のマルチタスキング能力に基づいた
遅い書込み（ｌａｚｙ ｗｒｉｔｅｓ、デファード書込
み又はライトビハインド（ｗｒｉｔｅ ｂｅｈｉｎｄ）
とも呼ばれている）を頼りにしているところが大きい。
例えば、プログラムがディスク書込みを要求する場合に
は、データはキャッシュ内に置かれ、キャッシュバッフ
ァがダーティとしてフラグされる（すなわち、ディスク
のデータの状態と一致しないことを示す）。ディスクが
アイドル状態になるか、或いはキャッシュがダーティバ
ッファで飽和されると、ファイルシステムは、ダエモン
プロセス（ｄａｅｍｏｎｐｒｏｃｅｓｓ）からのキャプ
ティプスレッド（ｃａｐｔｉｖｅ ｔｈｒｅａｄ）を用
いてバッファをディスクに書き込み、最も古いデータで
スタートする。キャプティブスレッド及びダエモンプロ
セスについては、Ｈａｓｔｉｎｇｓ、その他の著者によ
るテキストシリーズ「マイクロソフト社のＯＳ／２プロ
グラマーズリファレンス（“Ｍｉｃｒｏｓｏｆｔ ＯＳ
／２Ｐｒｏｇｒａｍｍｅｒｓ Ｒｅｆｅｒｅｎｃｅ”」
（１９８９年、Ｍｉｃｒｏｓｏｆｔ Ｐｒｅｓｓ社刊）
において説明されている。一般に、遅い書込みは、プロ
グラムがより高速で実行されることを意味している。な
ぜならば、一般に、プログラムの読取りリクエストは、
書込みリクエストを待機して遅延することなく完了する
からである。繰り返し読み取られるプログラムの場合
は、小さなワーキングセットを変更して書き込むので、
遅い書込みはまた、多くの不必要なすなわち冗長な物理
ディスク書込みを回避することができる。遅い書込みは
それらの或る危険性を有しており、従って本発明は、Ｄ
ｏｓＯｐｅｎに対してＯｐｅｎＭｏｄｅパラメータのラ
イトスルーフラグ（ｗｒｉｔｅ−ｔｈｒｏｕｇｈ ｆｌ
ａｇ）を設定することにより、パーハンドルベース（ｐ
ｅｒ−ｈａｎｄｌｅ ｂａｓｉｓ）上で遅い書込みに打
ち勝ち、ＤｏｓＲｅｆＲｅｓｅｔ機能により、パーハン
ドルベース上のディスクにデータを委託（ｃｏｍｍｉ
ｔ）することができる。ＯＳ／２の現行バージョンにお
いても、ＤｏｓＯｐｅｎ及びＤｏｓＢｕｆＲｅｓｅｔの
両機能を利用することができる。遅い書込み（ｌａｚｙ
ｗｒｉｔｅ）の広範囲な使用により、ＨＰＦＳが、あ
らゆる緊事態の下での書込みエラーから優雅に回復でき
るようになる。例えば、書込みの失敗が知られるときま
でに、アプリケーションは長時間を要する。なぜなら
ば、アプリケーションは、データをディスク記憶装置内
に安全に運び出したという錯覚の下で行われるからであ
る。ディスクアダプタにより戻される「セクタが見つけ
ないエラー（“ｓｅｃｔｏｒ ｎｏｔ ｆｏｕｎｄ”ｅ
ｒｒｏｒ）」のようなエラーは、ハードウェアにより検
出することができる。或いは、そのようなエラーは、デ
ータの書込み後、読取り検証（ｒｅａｄ ａｆｔｅｒ−
ｗｒｉｔｅ ｖｅｒｉｆｉｃａｔｉｏｎ）中、ハードウ
ェアのディスクドライバにより検出される。書込みエラ
ーを取り扱う主要機構は、ホットフィックス（ｈｏｔｆ
ｉｘ）と呼ばれる。エラーが検出されると、ファイルシ
ステムは、リザーブされたネットフィックスプールから
空きブロックを取り出し、該ブロックにデータを書込ん
で、ホットフィックスマップを更新する（ホットフィッ
クスマップとは、単に、一連の対をなす二重ワードのこ
とであり、二重ワードの各対は、そのホットフィックス
交換の番号と関連する番号の悪いセクタを収容してい
る）。次に、ホットフィックスマップのコピーがスペア
ブロックに書き込まれ、ディスク装置に問題があること
をユーザに知らせる警告メッセージがディスプレイされ
る。ファイルシステムがディスクドライバからのセクタ
読取り又は書込みを要求する度毎に、ファンシステム
は、ネットフィックスマップを走査して、悪いセクタの
番号を実際のデータを保持している良いセクタに相当す
る番号に置き換える。ＣＨＫＤＳＫの１つのデューティ
はホットフィックスマップを空にすることである。ホッ
トフィックスマップの各交換ブロックに対し、ＣＨＫＤ
ＳＫは、データを所有するファイルに対する好ましい位
置にある新しいセクタを割り当て、データをホットフィ
ックスブロックから新しい割り当てられたセクタに移動
させ、かつ、ファイルの割当て情報（この情報には、再
バランスしている割当てツリー及び他の精巧な作業が含
まれている）を更新する。次いで、ＣＨＫＤＳＫは、悪
いブロックリストに悪いセクタを付加し、交換セクタを
解放してホットフィックスプールに戻し、ホットフィッ
クスマップからホットフィックス入口を削除し、かつ、
更新したホットフィックスマップをスペアブロックに書
き込む。ＨＰＦＳは、かくＨＰＦＳボリュームのスペア
ブロックにダーティＦＳフラグを維持するＨＰＦＳボリ
ームの全てのファイルが閉じられるとき、キャッシュ内
の全てのダーティバッファが書き込まれるとき、或い
は、ブートボリュームの場合にはシャットダウンが選択
されかつその作業を完了したときに、フラグがクリアさ
れる。ＯＳ／２のブートシーケンス中に、ファイルシス
テムが各ＨＰＦＳ上のダーティＦＳフラグを検査して、
フラグが設定されている場合には、ＣＨＫＤＳＫが実行
されるまでブートボリュームには更にアクセスできない
ようにする。ブートボリュームにダーティＦＳフラグが
設定されている場合には、システムは自動的にＣＨＫＤ
ＳＫを実行する。スーパーブロック又はルートディレク
トリの損失というような眞に重大な事故には、最も成功
の可能性のあるデータ回復を与えることができるように
ＨＰＦＳが設計されている。Ｆｎｏｄｅ、割当てセクタ
及びディレクトリブロックを備えた殆ど全ての形式の重
要なファイル目的（オブジェクト）が、その親及び子の
両方に二重にリンクされており、かつ、ユニークな３２
ビットのサインを収容している。Ｆｎｏｄｅはまた、そ
れらのファイル又はディレクトリのネームの最初の部分
を収容している。従って、ＳＨＯＤＳは、Ｆｎｏｄｅ、
割当てセクタ及びディレクトリブロックに対してディス
クを規則正しく走査し、Ｆｎｏｄｅ、割当てセクタ及び
ディレクトリブロックを用いてファイル及びディレクト
リダイアグラムに空きスペースのビットマップを再創出
（ｒｅｇｅｎｅｒａｔｉｎｇ）することにより、全ボリ
ュームをリビルドすることができる。上記のように、本
発明は、ファイル及びディレクトリを理論的に順序付け
するのに、Ｂ＋ツリー及びＢ−ツリー（２進ツリー）を
用いている。２進ツリーは、データを物理的に順序付け
することなくして、ポインタを用いてデータ項目の集合
を論理的に順序付けする技術である。図１２を参照すれ
ば、簡単な２進ツリーにおける各ノードには、ツリーに
おるノードの論理的位置を決定するキー値を含む或るデ
ータと、並びにノードの左右のサブツリーを指すポイン
タとが設けられている。ツリーを開始するノードはルー
ト（根）として知られており、ツリーの枝の端部に位置
するノードは、ときどきリーフ（葉）と呼ばれている。
データの特定ピースを見出すには、２進ツリーがルート
を横切るようにする。各ノードにおいて、所望のキーが
ノードのキーと比較される。両キーが一致しない場合に
は、所望のキーがノードのキーより小さいか大きいかに
基づいて、ノードのサブツリーの１つのブランチ又は他
のブランチが選択される。このプロセスは、一致が見出
されるまで、又は図１２に示すように空のサブツリーに
出合うまで続けられる。このような簡単な２進ツリー
は、理解と実施が容易であるけれども、実用に際しての
欠点を有している。キーが非ランダムな態様でツリーに
首尾良く分散されなかった付加されなかったりすると、
ツリーが全く非対称的になり、ツリーの横断時間が広範
囲に変化してしまう。アクセス時間を均一にするため、
多くのプログラマは、図５に示すようなＢ−ツリーとし
て知られているバランス形ツリーを好む傾向にある。Ｂ
−ツリーについての重要な点は、データが全てのノード
に記憶され、１つ以上のデータ項目が１つのノードに記
憶され、かつ、ツリーの全てのブランチが同じ長さをも
っているということである。Ｂ−ツリーの最悪の場合の
挙動（ｂｅｈａｖｉｏｒ）は予測可能であり、簡単な２
次ツリーの挙動より遙かに良好であるが、Ｂ−ツリーの
メインテナンスはかなり複雑である。新しいデータ項目
ノ付加、キーバリューの変更、又はデータ項目の削除に
より、ノードのスプリッティング（分割）又はマージン
グ（併合）が生じ、これにより、ツリーには他の作業の
カスケードが強制される。図１３に示すように、Ｂ＋ツ
リーは、２つのノード形式（内部ノードは他のノードを
指すだけであり、外部ノードは実際のデータを有してい
る）をもつＢ−ツリーの特殊化されたフォームである。
Ｂ−ツリーよりもＢ＋ツリーの優れている点は、Ｂ＋ツ
リーの内部ノードが、Ｂ−ツリーの中間レベルノードよ
り非常に多くの決定バリューを保持でき、そのため、ツ
リーの外のファンが高速になりかつブランチの平均長さ
が短くなることである。これにより、必要データを見出
すにはＢ＋ツリーのヴランチがその端部に続かなければ
ならないという事実を補償でき、一方、Ｂ−ツリーにお
いては、データは中間ノードにおいて発見され、或い
は、ルート（根）においてさえも発見される。本発明
は、ＯＳ／２オペレーティングシステムを改善したもの
であり、多くのユーティリティとＯＳ／２の現行バージ
ョンにおいて利用できるサブルーチンを用いて実施する
ことができる。本発明は、主としてＯＳ／２オペレーテ
ィングシステムに使用することを意図しているが、本発
明の原理は、実際のあらゆるコンピュータのオペレーテ
ィングシステムに適用できるものである。ここで説明す
る新しいユーティリティ及びサブルーチンを除き、他の
全てのユーティリティ及びサブルーチンは現在利用され
ていて良く知られたものである。ＯＳ／２オペレーティ
ングシステムの詳細な説明については、前述のＯＳ／２
プログラマ用参考書を参照されたい。本発明の改善され
たＯＳ／２オペレーティングシステムのボリュームマネ
ージメント（ｖｏｌｕｍｅ ｍａｎａｇｅｍｅｎｔ）
は、ＯＳ／２の従来のバージョンにおいて行われている
ものと同じデューディ、すなわち、悪いボリュームがド
ライブにインサートされたときの検出、ボリュームが除
去されたときの検出、ボリュームパラメータブロック
（ＶＰＢ）を介してドライブ内に置かれた新しいメディ
アに関する新しい情報の創出、適当なデバイスドライバ
との通信、新しいインサートメディアにアクセスする必
要のあるデバイス情報をシステムに与えること、バッフ
ァ及びＣＤＳ機構とのインターフェース、及び特定ボリ
ュームへの変更をシステムに知らせること等に応答する
ことができる。ＯＳ／２の従来のバージョンにおいて
は、僅かに１つのファイルシステムがあったに過ぎな
い。本発明によれば、統一された環境内に多数のファイ
ルシステムを設けることができる。ボリュームマネージ
ャは、どのファイルシステムを特定のボリュームにアク
セスさせるべきかを決定し、ファイルシステムドライバ
（ＦＳＤｓ）が特定のボリュームについてのそれらの資
源（ｒｅｓｏｕｒｃｅｓ）を管理（マネージ）できるよ
うにする機構を提供し、かつボリュームの管理のために
過去に設けられた全てのＦＳＤｓに対して同じサポート
を提供する。本発明は、良く知られている既存のＯＳ／
２呼び出し（ＯＳ／２ ｃａｌｌｓ）並びに以下に説明
する幾つかの新しい機能を有している。本発明の設置可
能（ｉｎｓｔａｌｌａｂｌｅ）なファイルシステムにつ
いての完全な説明は、マイクロフィッシュの形態で本願
に添付されかつ参考として掲示する付録Ｉ（Ａｐｐｅｎ
ｄｉｘＩ）において述べられている。本発明は、個々の
ボリュームについての正しいファイルシステムドライバ
の識別及びローディングが容易に行えるマウンドプロセ
ス及びアンマウントプロセスを用いることを意図してい
る。マウントプロセスは、幾つかの異なる事象が生じた
とき、すなわち、 １． ボリュームへの最初のアクセスがあったとき、 ２． ドライブのボリュームが不確実になる（このこと
は、通常、ユーザが新しいメディアをドライブに入れる
ことを意味する）全てのとき、 ３． ドライブ内にないボリュームへのアクセスが要求
される全てのとき、に開始される。 マウントプロセスへの入力は、ドライブパラメータブロ
ック（ＤＰＢ）（このドライブパラメータブロックは、
デバイスドライバにＩ／Ｏを行うこと、及びドライブ内
にあると現在考えられているボリュームのＶＰＢにハン
ドルを記憶させることに使用される）を指すポインタで
ある。マウント作業によりこれが更新される。ローカル
ＶＰＢがスタック上に割り当てられ、ＤＰＢポインタと
共に初期化される。図１５に示すように、項目６０２で
示すようにメディアの論理的セクタ０を読み取ることに
より、マウントプロセス６００が開始される。デバイス
ドライバからの全てのエラーは無視する。なぜならば、
異なる形式のメディア（すなわち、光学ディスク又はＣ
Ｄ−ＲＯＭ）がトラック０を読取り不能にできるからで
ある。論理的セクタ０を読み取る前に、テンポラリマウ
ントバッファが０に初期化される。ボリュームのラベル
テキストフィールドが「ＵＮＬＡＢＥＬＥＤ」に初期化
される。セクタ０がチェックされ、特定バリュー（４
１）に対してサインバイト（ｓｉｇｎａｔｕｒｅｂｙｔ
ｅ）を比較することにより、フォーマットが認識されて
いるか否かを決定する。フォーマットが認識されていな
い場合には、ＶＰＢに近い情報がスタック上に充填され
る（すなわち、３２ビットボリューム連続番号（３２
Ｂｉｔ Ｖｏｌｕｍｅ Ｓｅｒｉａｌ Ｎｕｍｂｅ
ｒ））。次に、項目６０４により、ＢＵＩＬＤＢＰＢ呼
び出し（ＢＵＩＬＤＢＰＢ ｃａｌｌ）が、ＤＰＢにお
いて特定化されたデバイスドライバに発行される。ＢＵ
ＩＬＤＢＰＢは、デバイスドライバによりエクスポート
（移出）される手順である。このＢＵＩＬＤＢＰＢ手順
については、付録Ｉにおいて詳細に説明されている。Ｂ
ＵＩＬＤＢＰＢは、装置の物理パラメータ（バイトパー
セクタ（ｂｙｔｅｐｅｒ ｓｅｃｔｏｒ）、セクタパー
トラック（ｓｅｃｔｏｒ ｐｅｒ ｔｒａｒｃｋ）等）
を学習させるべく呼び出される。デバイスドライバは、
ボリュームの物理パラメータを決定するのに用いること
ができる情報を収容しているパッファを指すポインタに
導かれる。殆どのドライバにとっては、これはセクタ０
であり、非常に古い幾つかのドライバにとっては、ＦＡ
Ｔの最初のセクタである。装置が、セクタ０から読み取
られるデータを解釈できない場合（例えば、この場合の
フロッピがＦＡＴではなく、従ってＦＡＴ ＩＤバイト
が意味をもたない場合）には、装置は最小のＢＰＢを戻
し、カーネル及びＦＳＤｓが必要なＩ／Ｏを行って、ボ
リュームを完全に識別できるようにする。前に創出され
たＢＰＢからの適合フィールド（ｒｅｌｅｖａｎｔ ｆ
ｉｅｌｄ）は、スタックのローカルＶＰＢ（すなわち、
Ｓｅｃｔｏｒｓ／ｔｒａｃｋ、Ｎｕｍｂｅｒ ｏｆ Ｈ
ｅａｄｓ、Ｔｏｔａｌ Ｓｅｃｔｏｒｓ、Ｓｅｃｔｏｒ
Ｓｉｚｅ）にコピーされる。新しいＶＰＢが割り当てら
れ、ローカルＶＰＢからの情報がそれにコピーされる。
次に、本発明によれば、ループ６０６に入り、項目６０
８で示すように、新しい創出されたＶＰＢ、論理的セク
タ０を指すポインタ、及びＶＰＢファイルシステムの独
立及び従属領域（ｉｎｄｅｐｅｎｄｅｎｔａｎｄ ｄｅ
ｐｅｎｄｅｎｔａｒｅａｓ）を指すポインタを備えたＦ
Ｓ ＭＯＵＮＴ（フラグ＝０）の入口点を呼び出すこと
により、各ＦＳＤをボール（ｐｏｌｌ）する。ＦＳＤは
ＦＳＨ ＤｏｖｏｌＩＯを呼び出し、ボリュームから他
のセクタを読み取る（それ自体のバッファを割り当てな
くてはならない）。ＦＳＤが、ＥＲＲＯＲ ＵＮＣＥＲ
ＴＡＩＮ ＭＥＤＩＡに戻る場合には、エラーが戻さ
れ、プロセスは、決定（ｄｅｃｉｓｉｏｎ）６１０によ
り示すように再スタートされる。ＦＳＤがブートセクタ
をサポートする場合には、ＦＳＤは、ブートセクタのフ
ァイルシステムのネームフィールドをチェックして、こ
れがネームフィールドを認識しているか否かを決定す
る。ＦＳＤがブートセクタをサポートしない場合には、
ＦＳＤがボリュームを認識しているか否かを決定すべ
く、装置へのＩ／Ｏが行われる。ＦＳＤがひとたびボリ
ュームを認識しているならば、項目６１２で示すよう
に、ＶＰＢファイルシステムの独立及び従属領域におけ
る適合フィールドを更新する。ＶＰＢファイルシステム
の独立及び従属領域については、図１６に関連して更に
詳細に説明する。この時点においては、ＦＳＤはＦＳ
Ｈｅｐｏｅｒ（ＦＳＨ）機能を発行して、新しいボリュ
ームが、本発明が管理する他の任意のボリュームと同じ
であるか否かを決定する。このＦＳ Ｈｅｌｐｅｒは、
ファイルシステムの独立及び従属領域にポインタを戻
す。次いでＦＳＤは、項目６１４で示すように、新しく
創出されたＶＰＢから古いＶＰＢへと情報をコピーす
る。新しい創出されたＶＰＢは、ＭＯＵＮＴの呼び出し
を行った後に破壊される。次に、ＦＳＤは、あらゆるバ
ッファを無効にするような古いＶＰＢに対してあらゆる
クリナップ作業（ｃｌｅａｎｕｐ ｗｏｒｋ）を行う。
これは、ドライブからボリュームが除去されていること
からである。本発明によれば、ひとたびＦＳＤがボリュ
ームを認識すると、リスト内に一致するものが見出され
る場合には新しいＶＰＢが除去される。リスト内に一致
するものが見出されない場合には、ＶＰＢは、マウント
されたＦＳＤｓのリストにリンクされる。ＦＳＤｓが認
識されない場合には、決定６１４及び項目６１６に示す
ように、ＶＰＢが空にされかつＦＡＴファイルシステム
がマウントされる。新しいボリュームがドライブにイン
サートされかつ古いボリュームに対してカーネルがもは
や関与しない場合には、本発明では、ＦＳＤにＦＳ Ｍ
ＯＵＮＴ（フラグ＝２）が発行され、これにより、この
ボリュームに割り当てられた資源の割当てを解除するよ
うになっている。本発明により、新しくインサートされ
たボリュームが、ドライブの最終ボリュームとは異なる
ものであることが検出された場合には、ＦＳＤに対しＦ
Ｓ ＭＯＵＮＴ（フラグ＝１）の呼出しが発行され、こ
れにより、除去されたボリュームに関するバッファ無効
のようなあらゆるクリナップ形式の作業を行うことがで
きる。ボリュームに対してもはやカーネルが関与しない
場合には、ＦＳ ＭＯ ＮＴ（フラグ＝２、ＵＮＭＯＵ
ＮＴ）が続いて行われる。新しくインサートされたボリ
ュームが、ドライブにおいて最終的に見出されたボリュ
ームと同じものである場合には、この呼出しは発行され
ない。本発明は、ＦＳＤにより要求される機能に対する
既存のカーネル資源を利用するのに、効率の良い機構を
用いることを意図するものである。より詳しくは、ＦＳ
Ｄがカーネル内に存在する機能を要求する場合には、Ｆ
ＳＤは、ファイルシステムヘルパ（ＦＳＨ）を呼び出す
（ｉｎｖｏｋｅ）ファイルシステムヘルパ呼出し（ｃａ
ｌｌ）を発行する。呼び出されたＦＳＨは、次に、要求
された情報を戻す。以下に、ファイルシステムヘルパに
ついて簡単に説明する。以下に述べる要約においては幾
つかの重要なファイルシステムヘルパがリストアップさ
れているけれども、必要に応じて付加的なファイルシス
テムヘルパを設けることができる。ファイルシステムヘ
ルパは、Ａｐｐｅｎｄｉｘ Ｉにおいて詳細に説明され
ている。ファイルシステムヘルパ（Ｆｉｌｅ Ｓｙｓｔｅｍ Ｈ
ｅｌｐｅｒｓ） ＦＳＨ ＧＥＴＶＯＬＰＡＲＭ：多くのＦＳ呼出し時
に、ＶＰＢへのハンドルがＦＳＤに導かれ、ＦＳＤが、
ＶＰＢのファイルシステムの独立及び従属領域にアクセ
スすることがしばしば必要になる。このヘルパは、その
ようなサービスを与えるものである。 ＦＳＨ ＤＯＶＯＬＩＯ：ＦＳＤが、特定のボリューム
に対してＩ／Ｏを行う必要があるときには、ＦＳＤは、
このヘルパを使用して、要求されたボリュームが実際に
ドライブ内にあることを保証し、適当なデバイスドライ
バを呼び出し、かつハードエラーを取り扱う。このヘル
パは、ＦＳＤ内で常時用いることができる。ＦＳ＿ＭＯ
ＵＮＴ呼出しの範囲内で呼び出されるとき、ＦＳＤはド
ライブのボリュームに適用される。しかしながら、ＦＳ
ＤがＦＳ＿ＭＯＵＮＴ呼出しに戻るまでは、ボリューム
の認識が完了していないので、ＥＲＲＯＲ ＵＮＣＥＲ
ＴＡＩＮ ＭＥＤＩＡが戻される場合には、ＦＳＤに注
意しなければならない。このことは、ドライブにおける
メディアの識別を試みる間に、メディアが不確実になっ
ていることを示すものである。また、このことにより、
ＦＳＤが認識を試みていたボリュームが除去されたこと
を示すようにすることもできる。この場合には、ＦＳＤ
は、ＦＳ＿ＭＯＵＮＴ呼出しに導かれたｈＶＰＢに取り
付けられた（ａｔｔａｃｈｅｄ）全ての資源を解放し、
ＥＲＲＯＲ ＵＮＣＥＲＴＡＩＮ ＭＥＤＩＡがＦＳ＿
ＭＯＵＮＴ呼出しに戻される。これにより、ボリューム
トラッキング論理が、マウントプロセスを再スタートす
るように命令される。ＦＳＨＤＵＰＬＩＣＡＴＥＶＰ
Ｂ：ＦＳ＿ＭＯＵＮＴ呼出しの間、入力ＶＰＢは、管理
されている他の１つのボリュームと同じボリュームにす
ることができる。新しいボリュームに関する更新情報を
創出しかつ古い複製ＶＰＢ（ｏｌｄｅｒ ｄｕｐｌｉｃ
ａｔｅ ＶＰＢ）への情報をコピーすることは、ＦＳＤ
の責任である。このヘルパは、古い複製ＶＰＢが存在し
ているか否かを決定し、存在している場合には、古い複
製ＶＰＢのファイルシステムの独立及び従属領域を指す
ポインタを戻し、これらの領域がＦＳＤによって更新さ
れるようにする。次いで、ＦＳＤは、ボリュームが除去
されているので、古いボリュームについてあらゆるクリ
ナップ作業を行う。上記のように、本発明は、可能な限
り、予め存在しているＯＳ／２資源を使用することを狙
ったものである。以下のリストは、本発明の作業中に呼
び出される機能の階層（ｈｉｅｒａｒｃｈｙ）を要約し
たものである。 本発明によれば、メディアが不確実であるか否か又はメ
ディアが最初にアクセスされたか否かが呼び出される。
本発明のボリュームマネージメント機能（ボリューム管
理機能）はライン１．により表される。最初のプロセス
は、ライン１．１で示すように、どのボリュームがシス
テムに表されたかを決定することである。ライン１．
１．１のＰｒｏｂｅ Ｃｈａｎｇｅは、デバイスドライ
バにアクセスすべく呼び出され、メディアの変化をデバ
イスドライバが検出したか否かを決定する。メディアの
変化が検出されたときは、ライン１．１．２においてＲ
ｅｓｅｔＭｅｄｉａが呼び出され、デバイスドライバが
メディアにＩ／Ｏできることを知らせる。次に、ライン
１．１．３においてＧｅｎｈＶＰＢが呼び出され、ボリ
ュームパラメータブロックが創出される。このプロセス
は、ＬｏｃｋＶＢｕｆが呼び出されてオペレーティング
システムのカーネル内のバッファをクリアしかつ直列化
（ａｅｒｉａｌｉｚｅ）するライン１．１．３．１と共
に開始する。ライン１．１．３．２においては、メディ
アブートセクタのデータが、オペレーティングシステム
のバッファに読み取られる。システムはライン１．１．
３．３に続き、該ライン１．１．３．３においては、Ｂ
ｕｉｌｄＢＰＢが呼び出されて（ｉｎｖｏｋｅｄ）、デ
ィスクドライバを呼び出し（ｃａｌｌ）、ブートパラメ
ータブロックを作る。次に、．ＦＳ＿ＭＯＵＮＴがライ
ン１．１．３．４に呼び出される。ＦＳ＿ＭＯＵＮＴに
おける最初のステップは、ライン１．１．３．４．１の
Ｂｍｐ Ｇｅｔを呼び出す。ライン１．１．３．４．１
は、ＢＰＢのバッファを設定すべく呼び出されカーネル
におけるメモリマネージメントユーティリティである。
ライン１．１．３．４においては、ＦＳＭｏｕｎｔＶｏ
ｌｕｍｅが呼び出されると、ＦＳＭｏｕｎｔＶｏｌｕｍ
ｅは、ＦＳＤｓのリストを介して反復し、サクセスに戻
るかリストの終部（エンド）に到達するまで、各ＦＳＤ
のＦＳ＿Ｍｏｕｎｔ手順を呼び出す。ライン１．１．
３．４．２においてＦＳＤがサクセスに戻ると、ＶＰＢ
Ｃｏｐｙが呼び出されて、ＢＰＢのコピーに対するテン
ポラリバッファを創出する。次に、ライン１．１．３．
４．３におけるＶＰＢＬｉｎｋが呼び出され、ＶＰＢを
チェーンにリンクさせ、該チェーンにおける次のＶＰＢ
を指すべくＢＰＢを設定し、現在のＶＰＢをリストの開
始に初期化する。ＶＰＢＦｉｎｄがライン１．１．３．
４．４に呼び出されてＶＰＢｓのチェーンを試験し、プ
ロセス中のＶＰＢと同じボリューム識別子を所有してい
るＶＰＢを見出す。複製ＶＰＢの識別子が。見出された
場合には、ライン１．１．３．４．５にＶＰＢｆｒｅｅ
が呼び出され、複製ＶＰＢがＶＰＢｓのリスト内に見出
された場合には、試験を受けてＶＰＢがＶＰＢから自由
になる。ＦＳＭｏｕｎｔＶｏｌｕｍｅが完了すると、Ｖ
ＰＢに適当なフィールドを設定するライン１．１．３．
５．にＳｅｔＶＰＢが呼び出される。ライン１．１．
３．６において、ＦｉｎｄＶＩＤが呼び出され、ボリュ
ーム識別子が見出される。メディアのセクタ０にブート
ブロックが見出されない場合には、ライン１．１．３．
７にＤｉｓｋＩＯが呼び出され、ボリュームのＢＰＢが
位置付けされる。ＦＳＤのＦＳ＿ＭＯｕｎｔルーチンが
サクセスに戻らない場合には、（残留）ＦＡＴファイル
システムのＦＳ＿Ｍｏｕｎｔ手順と論理的に等価のイン
ラインコードが呼び出される。ライン１．１．３．８に
おいては、ＣＲＣが呼び出されて、古いＦＡＴボリュー
ムの最初のディレクトリが検査合計（ｃｈｅｃｋｓｕ
ｍ）され、それらのブートセクタの連続番号をもたない
ボリュームについてのユニークなボリューム連続番号が
創出される。次に、ライン１．１．３．９〜ライン１．
１．３．１３にリストアップされた機能が呼び出され
て、新しいボリューム識別子が創出されかつボリューム
識別子バッファが空にされる。ライン１．１．２．１４
においてはＢｕｆｌｎｖａｌｉｄａｔｅが呼び出され
て、プロセス開始以来メディアが変化している場合には
バッファ内の全てのデータが無効にされる。その場合に
は、ライン１．１．３．１５にＦｌｕｓｈＢｕｆが呼び
出され、新しいメディアに対してバッファをフラッシュ
させる。 ボリュームについて前から存在しているＶＰ
Ｂが見出されない場合には、ライン１．１．４のＩｎｃ
ＶＰＢＲｅｆが呼び出されて、現在のＶＰＢの基準カウ
ンタが増大（ｉｎｃｒｅｍｅｎｔ）される。この基準カ
ウンタは、ここで問題にしているボリュームが、オペレ
ーティングシステムのカーネルに対して依然として開放
しているか否かを記録するのに使用される。ライン１．
１．５においては、ＤｅｃＶＰＢＲｅｆが呼び出され、
前のＶＰＢの基準カウンタが減少（ｄｅｃｒｅｍｅｎ
ｔ）される。基準カウンタがゼロに減少された場合は、
ＶＢＰＦｒｅｅがライン１．１．５．１に呼び出され、
ＶＰＢが空にされる。ライン１．１．６にはＲｅｓｅｔ
Ｃｕｒｒｅｎｃｙが呼び出され、現在のディレクトリ構
成における位置データが無効であるとしてマークする。
ＮｅｘｔＣＤＳ（ライン１．１．６．１）及びＰｏｉｎ
ｔＣｏｍｐ（ライン１．１．６．２）は、現在のディレ
クトリ構成（ＣＤＳｓ）を列挙するのに用いられる内部
ルーチンである。ライン１．１．６．３においてＢｕｆ
Ｉｎｖａｌｉｄａｔｅが呼び出され、ファイルシステム
のバッファプールから、（現在は陳腐化している）ＶＰ
Ｂ基準が除去される。上記のように、ＶＰＢは、コンピ
ュータシステムに使用されている特定のボリュームにつ
いての情報を記憶するシステムにより用いられる。ボリ
ュームは、ブロック装置におけるメディアとして構成さ
れ、メディアに関する情報は、このボリュームを他の全
てのボリュームから区別する。ＶＰＢｓは、ＢＭＰとし
てセグメントに維持される。従って、システムは記録が
使用されているトラックのみを必要とし、かつ空のリス
トが管理される。新しいボリュームに出合う度毎に、す
なわち、ボリュームのＶＰＢ作製（ＶＰＢ ｂｕｉｌ
ｔ）がシステムに既存のいかなるＶＰＢｓとも一致しな
い度毎に、新しい入口（ｎｅｗｅｎｔｒｙ）が、ＢＭＰ
管理されたセグメント内で割当てられ、メディアからの
等価データで充填される。システムがＶＰＢが完了する
度毎に、すなわち、システムのＲｅｆＣｏｕｎｔがゼロ
になる度毎に、ＢＭＰ管理されたセグメントの入口が空
になり、ＢＭＰは、この空になった記憶機構（ｓｔｏｒ
ａｇｅ）を再使用のためにトラックする。テーブルＩの
機能により用いられた構成を以下に説明する。ＶＰＢ
は、次の３つの部分に分割される。 １． カーネルのプライベート部分。この部分は、情報
をカーネルに維持するのに使用され、ＶＰＢ（例えば、
基準カウント）の管理を必要とする。これは、カーネル
にとってのプライベートなものであり、ＦＳＤｓは決し
てこのプライベート部分にアクセスしないしかつこれを
変更することがないことを意味している。 ２． ファイルシステムの独立部分。この部分は、全て
のファイルシステムにより使用されかつ特定のあらゆる
ファイルシステムから独立している。この部分は、或る
ファイルシステム（ｆｉｌｅ ｓｙｓｔｅｍ、「Ｆ
Ｓ」）の要求に応じて、設置可能なファイルシステムに
導かれる。 ３． ＶＰＢを用いているファイルシステムに特有の部
分。この部分は、必要に応じてファイルシステムを使用
できる「作業領域」として設定される。この部分は、或
るＦＳの要求に応じてＩＦＳに導かれる。ＶＰＢのレイ
アウトは図１６に示されている。次の構成は、ファイル
システムのＶＰＢとは独立した部分を明らかにするもの
である。この構成は、ファイルシステムの形式の如何に
係わりなく、あらゆるファイルシステムにより使用でき
るものである。 下記の構成は、ＶＰＢのファイルシステムの従属部分を
定めるものである。この構成は、適合すると考えられる
ファイルシステムにより使用される。 下記の構成は、ボリュームパラメータブロック（ＶＰ
Ｂ）の構成を定めるものである。 下記の構成は、ＦＳＨ ＧＥＴＶＯＬＰＡＲＭ（これ
は、ＶＰＢハンドルからＶＰＢデータを得るのに使用さ
れる）により使用される。 下記の構成は、ＦＳＨ ＤＯＶＯＬＩＯ（これは、ボリ
ュームベース形セクタ配向転送（ｖｏｌｕｍｅ−ｂａｓ
ｅｄ ｓｅ−ｃｔｏｒ−ｏｒｉｅｎｔｅｄ ｔｒａｎｓ
ｆｅｒｓ）に使用される）により使用される。 下記の構成は、ＦＳＨ ＤＵＰＬＩＣＡＴＥＶＰＢ（こ
れは、複製（古い）ＶＰＢへのＶＰＢデータを得るのに
使用される）により使用される。 ＲｅｄｅｔｅｒｍｉｎｅＭｅｄｉａは、下記に示すよう
な特殊な組の入口パラメータ（ｅｎｔｒｙ ｐａｒａｍ
ｅｔｅｒｓ）を有している。 下記の呼び出しは、ボリューム管理の内部コンポーネン
トインターフェースに使用される。ＧｅｎｈＶＰＢは、
特定のドライブの内部ＶＰＢの決定に使用される。戻さ
れた全てのエラーは、ユーザに送られる。 全てのレジスタは、変更することができる。Ｂｕｉｌｄ
ｄＢＰＢは、古いディスク（すなわち、認識されたプー
トセクタを有していないディスク）用の正しいＢＰＢを
創出すべく呼び出される。新しいディスクは、ブートセ
クタ内に、ＫＮＯＷＮ（既知）で正しいすなわち正当な
ＢＰＢ（ＶＡＬＩＤ ＢＰＢ）を有している。デバイス
ドライバへのバッファは、ＢｕｉｌｄＢＰＢ呼び出しの
一部である。 全てのレジスタは、ＢＰを除く全てを変更した。ＦＳＭ
ｏｕｎｔＶｏｌｕｍｅは、ＩＦＳドライブが、関心をも
つボリュームを認識しているか否かを決定すべくチェッ
クする。ＦＳＭｏｕｎｔＶｏｌｕｍｅは、各ＦＳドライ
バのＦＳ＿Ｍｏｕｎｔ入口点を呼び出すＦＳＤチェーン
を通してループし、ＩＦＳが、関心をもつボリュームを
認識しているか否かを決定する。このループは、最初の
ＩＦＳがボリュームを認識するとき、又はシステム内に
設置されたＦＳドライバの番号のループカウンタが０に
減少するときに、終端する。 変更されたレジスタ；ａｘ，ｂｐ，ｂｘ，ｄｉ，ｅｓ，
ｓｉ，ＶＰＢＦｒｅｅは、リンクリストからＶＰＢを除
去して、セグメントからそのブロックを空にする。 ＶＰＢＬｉｎｋは、リストの開始時に新しいＶＰＢをイ
ンサートし、新しいＶＰＢ及び古い最初のＶＰＢの前方
及び後方のリンクフィールドを調節する。 ＶＰＢＦｉｎｄは、内部リストを走査して、入力ＶＰＢ
と同じボリュームＩＤをもつＶＰＢを探す。 ＶＰＢＣｏｐｙは、ローカル領域からＢＭＰ管理領域に
ＶＰＢをコピーし、かつ正当であるとしてＶＰＢをスタ
ンプする。 悪いボリュームがマウントされたときにこれを検出して
オペレータに正しい処置をとるように知られること、す
なわちボリュームマネージメント（ボリューム管理）
は、オペレーティングシステムのカーネル及び適当なデ
パイスドライバを介して直接行われる。本発明の原理に
よれば、各ファイルシステムドライバ（ＦＳＤ）は、ボ
リュームラベルと、ファイルシステムに使用される各ボ
リュームについての３２ビットのボリューム連続番号と
を創出するようになっている。これらは、ボリュームが
フォーマット化されるときに、理論的セクタゼロのリザ
ーブされた位置に記憶させるのが好ましい。この情報を
記憶するのに、特別のフォーマットが必要になることは
ない。オペレーティングシステムのカーネルは、ＦＳＤ
を呼び出して、これを含むことがある作業を実行する。
ＦＳＤは、ボリュームラベル又は連続番号が変更された
場合には、いつでもボリュームパラメータブロック（Ｖ
ＰＢ）を更新する。ＦＳＤがＩ／ＯリクエストをＦＳヘ
ルパルーチンに導くと、デバイスドライバは、３２ビッ
トのボリューム連続番号及びボリュームラベルを（ＶＰ
Ｂを介して）導く。ボリュームに関してＩ／Ｏが実行さ
れるとき、オペレーティングシステムのカーネルは、リ
クエストされたボリュームの連続番号を、装置を維持し
ている現在のボリュームの連続番号と比較する。これ
は、ドライブにマウントされたボリュームのドライブパ
ラメータブロック（ＤＰＢ）のＶＰＢをチェックするこ
とにより行われるインストレージ試験（ｉｎ−ｓｔｏｒ
ａｇｅ ｔｅｓｔ）であり、いかなるＩ／Ｏも必要とさ
れない。比較の結果、等しくない場合には、オペレーテ
ィングシステムのカーネルは、クリチカルエラーハンド
ラに信号を発生して、特定の連続番号及びラベルをもつ
ボリュームをユーザがインサートすることを促進させ
る。メディアの変化が検出されると、アプリケーション
プログラムのインターフェース（ＡＰＩ）の機能呼び出
しの代わりに、ドライブがアクセスし、本発明によれ
ば、そのボリュームに対するマネージングＩ／Ｏに応答
できるファイルシステムドライバ（ＦＳＤ）が決定され
る。次に、本発明は、ボリュームパラメータブロック
（ＶＰＢ）を割当て、設置されたＦＳＤｓをボーリング
（ｐｏｌｌ）する。ＦＳＤは、これがメディアを認識し
ていることを表示する。ＦＳＤｓは上記のようにしてボ
ーリングされる。ＦＡＴのＦＳＤは、ＦＳＤｓのリスト
の最後にあり、他のＦＳＤの認識が生じない場合には、
全てのメディアを認識することにより、省略時ＦＳＤ
（ｄｅｆａｕｌｔＦＳＤ）として作用する。本発明の原
理によれば、ファイルシステムドライバには、次の２つ
のクラス、すなわち、 １． ローカルすなわち遠隔（仮想ディスク）装置に対
してＩ／Ｏを行うブロックデバイスドライバを用いてい
るＦＳＤ（これは、ローカルファイルシステムと呼ばれ
ている）と、 ２．ブロックデバイスドライバを用いることなくして遠
隔システムにアクセするＦＳＤ（これは、遠隔ファイル
システムと呼ばれている）とがある。ドライブレター
（ドライブ文字）と遠隔ファイルシステムとの間の連結
はプログラムされたインターフェースを介して行われ
る。システムのネームスペース（例えば、ドライブ）の
目的とＦＳＤとの間の結合を生じさせるには、ＤｏｓＦ
ＳＡｔｔａｃｈシステムの呼出しが用いられる。疑似文
字装置（ｐｓｅｕｄｏ−ｃｈａｒａｃｔｅｒ ｄｅｖｉ
ｃｅ）と遠隔ファイルシステムとの間の連結も、Ｄｏｓ
ＦｓＡｔｔａｃｈインターフェースを介して行われる。
ＤｏｓＦｓＡｔｔａｃｈインターフェースは、ＤｏｓＦ
ｓＡｔｔａｃｈ呼出し及びＤｏｓＱＦｓＡｔｔａｃｈ呼
出しで構成されており、これらは、Ａｐｐｅｎｄｉｘ
Ｉにおいて詳細に説明されている。ローカルボリューム
が最初に参照されるとき、本発明では、ＦＳＤチェーン
の各ローカルＦＳＤを連続的に尋ねて（ａｓｋ）、各Ｆ
ＳＤのＦＳ＿ＭＯＵＮＴ入口点への呼出しを介してメデ
ィアを受け入れるようになっている。どのＦＳＤもメデ
ィアを受け入れない場合には、メディアは、省略時ファ
イルシステムに割り当てられる。ＦＯＲＭＡＴでは認識
されないメディアにアクセスするため行われる他の全て
の試みがなされて、「無効（正しくない）メディアフォ
ーマット（ＩＮＶＡＬＩＤ ＭＥＤＩＡ ＦＯＲＭＡ
Ｔ）」のエラーメッセージが出される。ひとたびボリュ
ームが認識されると、ドライブと、ＦＳＤと、ボリュー
ムの連続番号と、ボリュームのラベルとの間の関係が記
憶される。ボリュームの連続番号及びラベルは、ボリュ
ームのパラメータブロック（ＶＰＢ）に記憶される。Ｖ
ＰＢは、開放ファイル（Ｉ／Ｏに基づくファイルハンド
ル）、サーチ及びバッファリファレンス（ｂｕｆｆｅｒ
ｒｅｆｅｒｅｎｃｅｓ）についてのオペレーティング
システムにより維持される。除去されたボリュームに対
する連続リクエストは、ＦＳ＿ＭＯＵＮＴを呼び出すこ
とによりボリュームについての設置されたＦＳＤｓのボ
ーリングを要する。認識しているＦＳＤにより戻された
ＶＰＢ及び既存のＶＰＢのボリューム連続番号及びボリ
ュームラベルが比較される。試験が成功した場合には、
ボリュームにＦＳＤがアクセスされる。これに対し、試
験が失敗した場合には、オペレーティングシステムがク
リチカルエラーハンドラに信号を伝達し、ユーザがボリ
ュームを矯正することを促進させる。メディアとＶＰＢ
との間の連結は、ボリュームの全ての開放ファイルが閉
じられるまでセーブされ、サーチリファレンス及びキャ
ッチシュバッファリファレンスが除去される。ボリュー
ムの変化によってのみ、次のアクセス時にメディアの再
決定がなされる。ブート可能で論理的に区分（ｐａｒｔ
ｉｔｉｏｎ）されたメディアに関するオペレーティング
システムの区分へのアクセスは、ＯＳ／２オペレーティ
ングシステムに利用できる機能セット（機能組）のよう
なフルオペレーティングシステムの機能セットを介して
行われる。ディスクの区分化の設計（ｄｉｓｋ ｐａｒ
ｔｉｔｉｏｎｉｎｇ ｄｅｓｉｇｎ）についての詳細な
説明が、前述のＯＳ／２プログラマ用参考書においてな
されている。本発明によれば、ネットワークを介してオ
ペレーティングシステムと通信する遠隔装置を識別する
ためのＤｏｓＱＦｓＡｔｔａｃｈ機能が提供される。Ｄ
ｏｓＱＦｓＡｔｔａｃｈの目的は、取り付け（ａｔｔａ
ｃｈ）られた遠隔ファイルシステム、ローカルファイル
システム、文字装置（ｃｈａｒａｃｔｅｒ ｄｅｖｉｃ
ｅ）、又は、ローカルＦＳＤ又は遠隔ＦＳＤに取り付け
られた疑似装置ネームに関する情報を尋ねることであ
る。ＤｏｓＱＦｓＡｔｔａｃｈを呼び出すシーケンスは
次の通りである。 ここで、ＤｅｖｉｃｅＮａｍｅは、コロン（：）を付し
た駆動文字（ｄｒｉｖｅ ｌｅｔｔｅｒ）を指すか、或
は文字又は疑似文字装置ネームを指し、ＦＳＡＩｎｆｏ
ＬｅＶｅｌの幾つかのバリューは無視する。Ｄｅｖｉｃ
ｅＮａｍｅが文字又は疑似文字であるときには、Ｄｅｖ
ｉｃｅＮａｍｅは、コロンを付した疑似文字の形態を有
するＡＳＣＩＺストリングである。ＤｅｖｉｃｅＮａｍ
ｅが、文字又は疑似文字の装置ネームであるときには、
そのフォーマットは、サブダイレクトリ呼出しのファイ
ルネームのフォーマットにおけるＡＳＣＩＩＺストリン
グのフォーマットであり＼ＤＥＶ＼のように示すのが好
ましい。序数（ｏｒｄｉｎａｌ）は、文字装置、疑似文
字装置又はドライブの組のリストのインデックスであ
る。序数は常に１からスタートする。リストの１つの項
目の序数位置は重要でない。序数は、リスト全体を厳格
にステップするのに使用される。序数から項目へのマッ
ピングは揮発性であり、ＤｏｓＱＦＡｔｔａｃｈに対す
る或る呼出しから次の呼出しまで変化することができ
る。ＦＳＡＩｎｆｏＬｅｖｅｌは、要求される情報のレ
ベルであり、ＤａｔａＢｕｆｆｅｒのデータがどの項目
に関するものであるかを決定する。レベル０×０００１
は、ＤｅｖｉｃｅＮａｍｅにより名付けられた特定のド
ライブ又は装置ネームのデータを戻す。序数のフィール
ド（欄）は無視する。レベル０×０００２は、序数によ
り選択された文字又は疑似文字装置のリストの入口のデ
ータを戻す。ＤｅｖｉｃｅＮａｍｅのフィールドは無視
する。レベル０×０００３は、序数によって選択された
ドライブのリストの入口のデータを戻す。Ｄｅｖｉｃｅ
Ｎａｍｅのフィールドは無視する。ＤａｔａＢｕｆｆｅ
ｒは戻り情報バッファ（ｒｅｔｕｒｎ ｉｎｆｏｒｍａ
ｔｉｏｎ ｂｕｆｆｅｒ）であり、次のフォーマット内
にある。 ｓｚＦＳＮａｍｅは、ＦＳＤにより移出（エクスポー
ト）されたＦＳＤネームであり、このネームは、必ずし
もブートセクタのＦＳＤネームと同じネームである必要
はない。ローカル文字装置（ｉＴｙｐｅ＝１）について
は、ｃｂＦＳＤＮａｍｅ＝０であり、ｓｚＦＳＤＮａｍ
ｅは、ゼロで終わるバイトのみを含んでいて、ｃｂＦＳ
ＡＤａｔａ＝０である。ローカルドライブ（ｉＴｙｐｅ
＝３）については、ｓｚＦＳＤＮａｍｅは、呼出しの時
点でドライブに取り付けられたＦＳＤのネームを含んで
いる。この情報はダイナミックに変化する。ドライブが
オペレーティングシステムのカーネルの常駐ファイルシ
ステムに取り付けられている場合には、ｓｚＦＳＤＮａ
ｍｅに“ＦＡＴ”又は“ＵＮＫＮＯＷＮ”が含まれるで
あろう。常駐ファイルは、マウントを拒むＦＳＤｓ以外
の任意のディスクに取り付けられるので、認識可能なフ
ァイルシステムを含んでいないディスクを設けることが
できるが、常駐ファイルシステムに取り付けることもで
きる。この場合、差異を検出することができ、この情報
は、破壊されないデータのプログラムが、適正に認識さ
れなかったディスクに存在することを助ける。Ｄａｔａ
ＢｕｆｆｅｒＬｅｎは、戻りバッファのバイト長さであ
る。戻り時においては、この長さは、ＦＳＤによりＤａ
ｔａＢｕｆｆｅｒに戻されたデータの長さである。 全てのブロック装置及び全ての文字及び疑似文字装置に
ついての情報は、ＤｏｓＱＦｓＡｔｔａｃｈにより戻さ
れる。この呼出しにより戻される情報は、揮発性が強
い。戻された情報は、これらが戻されるときまでに既に
変化されていることを呼出しプログラムが気付くことが
できるようにするのが好ましい。カーネルの常駐ファイ
ルシステムに取り付けられたディスクに戻された情報
は、ディスクがファイルシステムを備えたものであるこ
とをカーネルが明確に認識しているか否かの決定、又は
カーネルがそのファイルシステムをカーネルに取り付け
たか否か（他のＦＳＤｓはディスクを取り付けていない
からである）の決定を行うのに使用することができる。
全てのＦＳＤｓへのエラー信号についてのエラーコード
の組は、０×ＥＥＯＯ−０×ＥＥＦＦである。必要に応
じて他のエラーを付加できるけれども、次のエラーが定
められている。ＥＲＲＯＲ ＶＯＬＵＭＥ＿ＮＯＴ Ｍ
ＯＵＮＴＥＤ＝０×ＥＥＯＯ−ＦＳＤは、ボリュームを
認識しなかった。各ＦＳＤにより定められるエラーコー
ドの組は、０×ＥＦＯＯ−０×ＦＥＦＦである。ディス
クメディア及びファイルシステムのレイアウトは、次の
構成により説明される。ファイルシステムに与えられる
データは、ブロック装置に取り付けられたデバイスドラ
イバにより与えられるファイルシステムサポートのレベ
ルに基づいている。これらの構成は、ローカルファイル
システムに対してのみ等価性を有している。 上記のように、ＦＳ ＭＯＵＮＴ機能は、ボリュームを
マウントしかつアンマウントすべく呼び出され、その目
的は、ＦＳＤがファイルシステムのフォーマットを認識
しているか否かを決定すべくボリュームを試験すること
にある。ＦＳ−ＭＯＵＮＴを呼び出すシーケンスは下記
の通りである。 ここで、フラグは、要求された作業を示す。ｆｌａｇ＝
０は、ボリュームをマウント又は受け入れるのにＦＳＤ
が要求されることを示す。ｆｌａｇ＝１は、特定のボリ
ュームが除去されたことをＦＳＤがアドバイスされてい
ることを示す。ｆｌａｇ＝２は、ボリュームがそのドラ
イバから除去されるときに当該ボリュームに割り当てら
れる全ての内部情報及び当該ボリュームが除去されたこ
との最終のカーネル管理リファレンスを開放するのにＦ
ＳＤが要求されることを示す。ｆｌａｇ＝３は、ＦＳＤ
に使用するためのフォーマット化の準備において、認識
の如何に係わらずボリュームを受け入れることをＦＳＤ
が要求されることを示す。他の全てのバリューはリザー
ブされる。ＦＳＤに導かれるバリューは正しいであろ
う。ｐｖｐｆｓｉ−ＶＰＢのファイルシステム独立部分
を指すポインタ。メディアが、オペレーティングシステ
ムの認識可能なブートセクタを収容している場合には、
ファイルされたｖｐｉ ｖｉｄは、ボリュームについて
の３２ビット識別子を収容する。メディアがそのような
ブートセクタを収容しない場合には、ＦＳＤは、メディ
アに対してユニークなラベルを創出して、該ラベルをフ
ァイルされたｖｐｉ ｖｉｄに配置する。ｐｖｐｆｓｄ
−ＶＰＢのファイルシステム従属部分を指すポインタ。
ＦＳＤは、必要に応じ情報をこの領域に記載させること
ができる。 ｈＶＰＢ−ボリュームへのハンドル。 ｐＢｏｏｔ−メディアから読み取られたセクタ０を指す
ポインタ。このポインタは、フラグ＝＝０のときにのみ
正当である。ポインタのバッファは、「ＭＵＳＴ ＮＯ
Ｔ ＢＥ ＭＯＤＩＦＩＥＤ（変更してはならない）」
を指示する。ポインタは常に正当であり、フラグ＝＝０
である場合にはその正当であることを確認する必要はな
い。読取りエラーが生じた場合には、バッファはゼロを
包含する。ＦＳＤは、もたらされたボリュームを試験
し、ボリュームがファイルシステムを認識しているか否
かを決定する。ボリュームがファイルシステムを認識し
ている場合には、ｖｐｆｓｉ及びｖｐｆｓｄの適当な部
分を充填した後に、ゼロに戻る。ｖｐｉ ｖｉｄ及びｖ
ｐｉ ｔｅｘｔのフィールドは、ＦＳＤにより充填され
る。ＦＳＤがオペレーティングシステムのフォーマット
ブートセクタを有している場合には、ＦＳＤは、メディ
アをラベルからａｓｃｌｉｚフォームに変換する。ｖｐ
ｉ ｈＤｅｖのフィールドは、オペレーティングシステ
ムにより充填される。ボリュームが認識されていない場
合には、ドライバは非ゼロ（ｎｏｎ−ｚｅｒｏ）に戻
る。ｖｐｉ ｔｅｘｔ及びｖｐｉ ｖｉｄは、これらの
バリューが変化する度毎により更新されるｖｐｆｓｄの
内容は次の通りである。 ＦＬＡＧ＝０ ＦＳＤはＦＳＤ ＦＩＮＤＤＵＰＨＶＰＢを発行して、
複製ＶＰＢが存在しているか否かを決定する。複製ＶＰ
Ｂが存在している場合には、新しいＶＰＢのｆｓ従属領
域が正しくなく、ＦＳＤがＦＳ＿ＭＯＵＮＴの呼出しか
ら戻った後に、新しいＶＰＢがアンマウントされる。Ｆ
ＳＤは、古いＶＰＢのｆｓ従属領域を更新する。複製Ｖ
ＰＢが存在しない場合には、ＦＳＤは、ｆｓ従属領域を
初期化する。 ＦＬＡＧ＝１ ＶＰＢのｆｓ従属部分は、ＦＳＤが最後にこの従属部分
を変更したものと同じである。 ＦＬＡＧ＝２ ＶＰＢのｆｓ従属部分は、ＦＳＤが最後にこの従属部分
を変更したものと同じである。メディア認識プロセスの
後、ＦＳＨ ＧＥＴＶＯＬＰＡＲＭ呼出しを用いて、ボ
リュームパラメータを試験することができる。ボリュー
ムパラメータは、メディア認識プロセスの後に変更すべ
きではない。マウントリクエストの間、ＦＳＤは、ＦＳ
Ｈ ＤＯＶＯＬＩＯを用いることによりメディアの他の
セクタを試験し、Ｉ／Ｏを行うことができる。不確実メ
ディアの戻りが検出される場合には、ＦＳＤは「ｃｌｅ
ａｎｓｕｐ（クリナップ）」の状態になってＥＲＲＯＲ
ＵＮＣＥＲ−ＴＡＩＮ ＭＥＤＩＡを戻し、新しいイ
ンサートされたメディアに関してボリュームマウント論
理が再スタートできるようにする。ＦＳＤは、付加Ｉ／
Ｏに使用できるバッファを設ける。オペレーティングシ
ステムのカーネルは、上記レフカウント（ｒｅｆｃｏｕ
ｎ）のかウンタを介してＶＰＢを管理する。全てのボリ
ューム特定目的（ｖｏｌｕｍｅｓｐｅｃｉｆｉｃ ｏｂ
ｊｅｃｔｓ）は、適当なボリュームハンドルでラベリン
グされ、ＶＰＢに対する基準を示す。ボリュームに対す
る全てのカーネル基準が消滅すると、フラグ＝２でＦＳ
＿ＭＯＵＮＴが呼び出され、ディスマウントリクエスト
を表示する。ボリュームがそのドライブから除去された
ことをカーネルが検出し、かつ、依然としてボリューム
に対する未解決の基準（ｏｕｔｓｔａｎｄｉｎｇ ｒｅ
ｆｅｒｅｎｃｅｓ）が存在すると、ＦＳ＿ＭＯＵＮＴは
フラグ＝１で呼び出され、ＦＳＤが、ボリュームについ
てのクリーンなデータ（又は、他の再生可能データ）を
記憶できるようにする。ダヒティで再生不可能なデータ
は、該データがドライブ内にリマウントされるときに、
ボリュームに書き込むことができるように保持される。
本発明の目的を得る上で、クリーンデータは変化されな
いデータであり、ダーティなデータは変更されたデータ
である。ＦＳＤに使用できるようにするためボリューム
をフォーマット化すべきときには、オペレーティングシ
ステムのカーネルは、フラグ＝３でＦＳＤのＦＳ＿ＭＯ
ＵＮＴ入口を呼び出し、ＦＳＤがフォーマット作業の準
備を行えるようにする。ＦＳＤは、ボリュームがＦＳＤ
の認識するボリュームでない場合でもボリュームを受け
入れる。フォーマットがボリュームに関してファイルシ
ステムを変化させるからである。フォーマット化を完了
できない場合（例えば、ＦＳＤがＣＤ−ＲＯＭのサポー
トする場合）には、作業は失敗するであろう。殆どのコ
ンピュータシステムのハードウェアは、メディアのカー
ネルメディア形除去（Ｋｅｒｎｅｌ−ｍｅｄｉａｔｅｄ
ｒｅｍｏｖａｌ ｏｆ ｍｅｄｉａ）ができないの
で、ボリュームがどのドライブにも存在しないときにア
ンマウントリクエストが発行されることは確実である。
ＦＳＨ＿ＤＯＶＯＬＩＯは、特定のボリュームに対する
Ｉ／Ｏを実行する。ＦＳＨ＿ＤＯＶＯＬＩＯは、リクエ
ストされたＩ／Ｏに対するデバイスドライバのリクエス
トパケットをフォーマット化し、デバイスドライバを呼
出し、かつＦＳＤに戻る前に、あらゆるエラーをハード
エラーダエモンに報告する。ハードエラーダエモンによ
り表示された全ての再試行（ｒｅｔｒｉｅｓ）又はＤＯ
ＳＥＲＲＯＲにより表示されたアクションは、ＦＳＨ＿
ＤＯＶＯＬＩＯへの呼出しを行っている間に行われる。
次に、ＦＳＨ＿ＤＯＶＯＬＩＯに対する呼出しフォーマ
ットについて説明する。 ここで、オペレーションビットマスク（ｏｐｅｒａｔｉ
ｏｎ ｂｉｔ ｍａｓｋ）は、実行すべきｒｅａｄ／ｒ
ｅａｄ−ｂｙｐａｓｓ／Ｗｒｉｔｅ／Ｗｒｉｔｅ−ｂｙ
ｐａｓｓ／ｖｅｒｉｆｙ−ａｆｔｅｒ−ｗｒｉｔｅ／ｗ
ｒｉｔｅ−ｔｈｒｏｕｇｈ及びノーキャッシュ作業（ｎ
ｏ−ｃａｃｈｅ ｏｐｅｒａｔｉｏｎ）を表示する。 Ｂｉｔ ０×０００１ ｏｆｆは、読取りを表示する。 Ｂｉｔ ０×０００１ ｏｎは、書込みを表示する。 Ｂｉｔ ０×０００２ ｏｆｆは、ｎｏ−ｂｙｐａｓｓ
を表示する。 Ｂｉｔ ０×０００２ ｏｎは、ｃａｓｃｈｅ ｂｙｐ
ａｓｓを表示する。 Ｂｉｔ ０×０００４ ｏｆｆは、ｎｏ ｖｅｒｉｆｅ
ｙ−ａｆｔｅｒ−ｗｒｉｔｅ作業を表示する。 Ｂｉｔ ０×０００４ ｏｎは、ｖｅｒｉｆｙ−ａｆｔ
ｅｒ−ｗｒｉｔｅを表示する。 Ｂｉｔ ０×０００８ ｏｆｆは、ハードエラーダエモ
ンに信号を送られたエラーを表示する。 Ｂｉｔ ０×０００８ ｏｎは、ハードエラーが直接戻
されることを表示する。 Ｂｉｔ ０×０００１０ ｏｆｆは、Ｉ／Ｏが“ｗｒｉ
ｔｅ−ｔｈｒｏｕｇｈ”でないことを表示する。 Ｂｉｔ ０×０００１０ ｏｎ は、このＩ／Ｏが“ｗ
ｒｉｔｅ−ｔｈｒｏｕｇｈ”であることを表示する。 Ｂｉｔ ０×０００２０ ｏｆｆは、このＩ／Ｏに対す
るデータを変更すべきことを表示する。 Ｂｉｔ ０×０００２０ ｏｎ は、このＩ／Ｏに対す
るデータを変更すべきではないことを表示する。 リザーブされた他の全てのビットはゼロである。「ｃａ
ｃｈｅ ｂｙｐａｓｓ（キャッシュバイパス）」と、
「ｎｏ ｃａｃｈｅ（のキャッシュ）」ビットとの間の
相違は、リクエストパケットの形式においてデバイスド
ライバが導かれることである。「ｃａｃｈｅ ｂｙｐａ
ｓｓ」では、コマンドコード２４、２５又は２６でパケ
ットが得られ、「ｎｏ ｃａｃｈｅ」では、システム
は、コマンドコード４、８又は９に対するバケットを拡
大する。 ｈＶＰＢ Ｉ／Ｏの資源に対するボリュームハンド
ル。 ｐＤａｔａ ユーザの転送領域（ｔｒａｎｓｆｅｒ
ａｒｅａ）の長いアドレス。 ｐｃＳｅｃ 転送すべきセクタ数を指すポインタ。 戻り時には、これは首尾良く転送されたセクタ数であ
る。 ｉＳｅｃ 転送の最初のセクタ数。 Ｒｅｔｕｒｎｓ −作業が失敗した場合には、０以外の
エラーコード。ＥＲＲＯＲ ＰＲＯＪＥＣＴＩＯＮ Ｖ
ＩＯＬＡＴＩＯＮ−供給されたａｄｄｒｅｓｓ／ｌｅｎ
ｇｔｈは正しくない。ＥＲＲＯＲ ＵＮＣＥＲＴＡＩＮ
ＭＥＤＩＡ−メディアが変更されているときには、デ
バイスドイバは信頼性をもって告げることはできない。
このことは、ＦＳ ＭＯＵＮＴのコンテクスト内におい
てのみ生じる。ＥＲＲＯＲ ＴＲＡＮＳＦＥＲ ＴＯＯ
ＬＯＮＧ−デバイスにとって転送が非常に短い。ＦＳ
Ｈ＿ＤＯＶＯＬＩＯは、常時、ＦＳＤ内で使用すること
ができる。ＦＳ＿ＭＯＵＮＴ呼出しの範囲内で呼び出さ
れるとき、ＦＳＨ＿ＤＯＶＯＬＩＯは、ボリュームの如
何に係わらず、ドライブのボリュームに適用される。し
かしながら、ＦＳＤがＦＳ＿ＭＯＵＮＴの呼出しに戻る
までは、ボリュームの認識が完了しないので、ＦＳＤ
は、ＥＲＲＯＲ ＵＮＣＥＲＴＡＩＮ ＭＥＤＩＡが戻
されないときには、特別な注意を払わなければならな
い。これは、ドライブにおけるメディアを識別するの
に、メディアが不確実な試みを行ったことを表示する。
また、ＦＳＤが認識を試みたポリュームが除去されたこ
とを表示するようにしてもよい。この場合、ＦＳＤは、
ＦＳ ＭＯＵＮＴの呼出し時に導かれたｈＶＰＢに取り
付けられたあらゆる資源を解放し、かつＥＲＲＯＲ Ｕ
ＮＣＥＲＴＡ−ＩＮＭＥＤＩＡをＦＳ＿ＭＯＵＮＴ呼出
しに戻す。これにより、マウントプロセスを再スタート
させるように、ボリュームトラッキング論理を仕向けら
れる。ＦＳＤｓは、ＦＳＨ ＤＯＶＯＬＩＯ２を呼出し
て、Ｉ／Ｏ作業とは独立して、デバイスドライバの作業
を制御する。このルーチンは、ＩＯＣＴＬ作業に対する
ボリューム管理をサポートしている。ＦＳＤに戻る前
に、全てのエラーがハードエラーダエモンに報告され
る。ハードエラーダエモンにより表示されるすべての再
試行又はＤＯＳＥＲＲＯＲにより表示されるアクション
は、ＦＳＨ ＤＯＶＯＬＩＯ２への呼出し内に行われ
る。 ここで、 ｈＤｅｖ−ＶＰＢから得られたデバイスハンドル。 Ｓｆｎ−ＦＳＨ ＤＥＶＩＯＣＴＬ呼出しを引き起こし
たオープンインスタンス（ｏｐｅｎ ｉｎｓｔａｎｃ
ｅ）からのシステムファイルの数。このフィールドは、
変化されない状態で、ｓｆｉ ｓｅｌｆｓｆｎのフィー
ルドから導かれるべきである。どのオーブンインスタン
スもこの呼出しに一致しないときには、このフィールド
は、０×ＦＦＦＦに設定される。 ｃａｔ −実行すべきＩＯＣＴＬのカテゴリ。 ｆｕｎｃ−ＩＯＣＴＬのカテゴリ内での機能。 ｐＰａｒｍ−パラメータ領域へのロングアドレス。 ｃｂＰａｒｍ−パラメータ領域の長さ。 ｐＤａｔａ−データ領域へのロングアドレス。 ｃｂＤａｔａ−データ領域の長さ。 Ｒｅｔｕｒｎｓ−エラーが検出されないときには０以外
のエラーコード。 供給された機能が、ここに述べているシステムとの互換
性をもたない場合には、ＥＲＲＯＲ ＩＮＶＡＬＩＤ
ＦＵＮＣＴＩＯＮが呼び出される。メディアが不確実に
なるときにはいつでも、新しいＶＰＢが割り当てられる
（メディアが変更されていないことがもはや確かではな
いことを、デバイスドライバは認識している）。このＶ
ＰＢは、ＦＳ ＭＯＵＮＴ呼出しが戻るまで、（メディ
アの再インサートにより）前に割り当てられたＶＰＢと
共に崩壊することはない。しかしながら、前のＶＰＢ
は、メディア（このメディアは、該メディアが除去され
ている間に書き込むことができる）から更新されなくて
はならない幾つかのキャッシュデータをもつことができ
る。古いＶＰＢについてのキャッシュ情報（ｃａｃｈｅ
ｄ ｉｎｆｏｒｍａｔｉｏｎ）を更新するため、ＦＳＨ
ＦＩＮＤＤＵＰＨＶＰＢは、ボリュームの、この前に
生じたことをＦＳＤが見出すことを可能にする。このボ
リュームについて別の古いＶＰＢが存在しない場合に
は、新しい創出されたＶＰＢがアンマウントされる。Ｆ
ＳＨ ＦＩＮＤＤＵＰＨＶＰＢについての呼出しフォー
マットは次の通りである。 ここで、 ｈＶＰＢ−見出すべきボリュームに対するハンドル。 ｐｈＶＰＢ−マッチングボリュームのハンドルをどこに
記憶させるかを指すポインタ。 Ｒｅｔｕｒｎｓ−マッチングＶＰＢが見出されないとき
には０以外のエラーコード。 ＥＲＲＯＲ ＮＯ ＩＴＥＭＳ−マッチングｈＶＰＢは
存在しない。ＦＳＨ ＧＥＴＶＯＬＰＡＲＭは、ＦＳＤ
が、ＶＰＢからファイルシステムの独立及び従属データ
を検索することを可能にする。ＦＳルータはＶＰＢハン
ドル内を通るので、ここのＦＳＤｓは、適合部分を指す
ポインタ内にハンドルをマッピングする。ＦＳＨ ＧＥ
ＴＶＯＬＰＡＲＭについての呼出しシーケンスは次の通
りである。 ここで、 ｈＶＰＢ−関心のあるボリュームハンドル。 ｐｐＶＰＢｆｓｉ−ファイルシステムの独立データを記
憶させるべくポインタが指す位置。 ｐｐＶＰＢｆｓｄ−ファイルシステムの従属データを記
憶させるべくポインタが指す位置。 Ｒｅｔｕｒｎｓ−なし。 ＦＳＤ Ｖｏｌｕｍｅのマッピングはダイナミックであ
り、かつＦＳＤ−ＤＤ連結は、ＦＳＤ及びＤＤの独立方
法により、オペレーティングシステムのカーネルを介し
て行われるので、あらゆるＦＳＤは、ＤＤｓがこのＦＳ
Ｄからローディングされたボリュームを含むあらゆるボ
リュームにアクセスできる。ボリュームは、除去可能な
メディアの特定のピース（片）、又は区分できる任意の
メディアの任意の区分にマッビングするので、多数のＦ
ＳＤｓが特定のハードディスク又は他のメディアにアク
セスできるようにしてもよい。ボリュームファイル作業
は、２つのカテゴリ、すなわち、ネームベース作業（ｎ
ａｍｅｄ−ｈａｓｅｄ ｏｐｅｒａｔｉｏｎｓ）及びハ
ンドルベース作業（ｈａｎｄｌｅ−ｂａｓｅｄ ｏｐｅ
ｒａｔｉｏｎｓ）に分けることができる。ネームベース
作業は一般にユーザによって開始され、システム１００
がファイルについてネーム作業を行うことをユーザがシ
ステム１００に命令（ｉｎｓｔｒｕｃｔ）する。ハンド
ルベース作業は、一般に、システムのバックグラウンド
作業中に開始される。通常、ハンドルベース作業は、ネ
ームベース作業の後に行われる。図１７に示すように、
コンピュータシステム１００がネームベース作業を行っ
ているときに、ルーチン８００が呼び出される。ネーム
ド作業は、文字ネームにより指示された作業である。す
なわち、この作業は、ファイル又はディレクトリのネー
ムにより特定化される。「Ｏｐｅｎ ｆｉｌｅ“ｘｘ
ｘ”」はネームベース作業の一例である。プロセス８０
２は、ネームをパーシング（ｐａｒｓｅ）すべく呼び出
されて、３つの変数すなわち、ＰａｔｈＮａｍｅＴｙｐ
ｅ、ＴＣＢＴｈｉｓｈＶＰＢ及びＴＣＢＴｈｉｓＦＳＣ
を戻す。このプロセス８０２については、図１８に関連
して詳細に説明する。（注、ｈはハンドルをいい、ＴＣ
Ｂは、ＴＣＨＴｈｉｓｈＶＰＢが現に関心をもっている
ＶＰＢへのハンドルでありかつＴＣＢＴｈｉｓＦＣＨが
関心のあるファイルシステムを指すポインタである、ス
レッド制御ブロック（ｔｈｒｅａｄ ｃｏｎｔｒｏｌ
ｂｌｏｃｋ）いう。）次に、項目８０４は、プロセス８
０２により戻された変数ＰａｔｈＴｙｐｅ、ＴｃｈＴｈ
ｉｓｈＶＰＢ及びＴＣＨＴｈｉｓＦＣＨに基づく適当な
機能に制御をルーチング（ｒｏｕｔｅ）する。ＵＮＣ
ＦＳＤが呼び出されるユニバーサルネーミングコンベン
ション（Ｕｎｉｖｅｒｓａｌ Ｎａｍｉｎｇ Ｃｏｎｖ
ｅｎｔｉｏｎ、「ＵＮＣ」）のグローバルネットワーク
を表示する「＼＼」で経路（ｐａｔｈ）が始まるときに
は、項目８０６を通る制御が行われる。ローカル装置が
表示される場合には、制御が項目８０８に導かれ、カー
ネル内でリクエストが処理される。疑似装置又は遠隔フ
ァイルが表示されるときには、制御は項目８１０に導か
れて、疑似装置又は遠隔ファイルが取り付けられた遠隔
ＦＳＤに対するリクエストをルーチングする。ネームド
パイプ（ｎａｍｅｄ ｐｉｐｅ）が検出された場合に
は、制御は項目８１２に導かれて、カーネル無しでロー
カルネームドパイプコードを呼び出す。ローカルファイ
ルが表示される場合には、制御は項目８１４に導かれ
る。この項目８１４は、項目８１６におけるＦＳＨＤＯ
ＶＯＬＩＯを呼び出すことによりボリュームへの読取り
及び書込みを行うＦＳＤにおけるＦＳＤワーカである。
ＦＳＨＤＯＶＯＬＩＯについては、図２０に関して更に
詳細に説明する。次に、図１８を参照して、パーシング
プロセス８０２を説明する。呼出しがあると、項目９０
２は、現在のドライブ、現在のディレクトリ及びネーム
自体に基づいて、関心のあるネームをカノニカルフォー
ム（ｃａｎｏｎｊａｌ ｆｏｒｍ）に変形する。次に、
変数ＴＣＢＴＨＩＳＦＳＣ、ＴＣＨＴｈｉｓＶＰＢ及び
ｐａｔｈｎａｍｅｔｙｐｅが下記のようにして決定され
るデシジョン９０４は、ユーザのネームが「＼＼」で始
まっているか否かを決定して、ＵＮＣネームが表示され
ているか否かを決定する。ＵＮＣネームが表示されてい
れば、制御が項目９０５に導かれ、ここで、変数ｐａｔ
ｈｔｙｐｅ、ＴｃｈＴｈｉｓｈＶＰＢ及びＴＣＢＴｈｉ
ｓＦＣＨが初期化され、ユーザのネームを適当な位置に
ルーチングする。ＵＮＣネームが表示されていなけれ
ば、デシジョン９０６は、関心をもつネームがカーネル
により維持された、装置のネームリストに載ったネーム
であるか否かを決定する。装置のネームリストに載った
ネームであるときには、デシジョン９０８は、それが疑
似文字装置であるか否かを決定する。疑似文字装置であ
れば、項目９１０は表示のように変数を設定する。疑似
文字装置でないときは、制御９１２に導かれ、表示のよ
うに変数を設定する。デシジョン９１４は、ネームの初
めにおける「＼ｐｉｐｅ＼」を探すことにより、そのネ
ームが、ネームドパイプであるか否かを決定する。その
ネームがネームドパイブであるときは、項目９１６は、
表示のように変数を設定する。ネームドパイブでないと
きは、デシジョン９１８は、そのネームがローカルドラ
イブ又は遠隔ドライブのパスネーム（ｐａｔｈｎａｍ
ｅ）を表示しているか否かを決定する。遠隔ドライブが
表示されているときは、制御は項目９２０に導かれ、こ
こでは、表示のように変数ＰａｔｈＴｙｐｅ、ＴｃｈＴ
ｈｉｓｈＶＰＢ及びＴＣＢＴｈｉｓＦＣＨを設定する。
遠隔ドライブが表示されていないときは、制御は項目９
２２に導かれ、ここでは、どのボリュームから適当なデ
ータを読み取るかが呼び出される。ＷｈａｔＶｏｌｕｍ
ｅが戻ると、制御は項目９２４に導かれ、ここでは、表
示のように変数ＰａｔｈＴｙｐｅ、ＴｃｈＴｈｉｓｈＶ
ＰＢ及びＴＣＢＴｈｉｓＦＣＨが設定される。図１９を
参照すると、プロセス１０００が呼び出され、ハンドル
ベース作業が行われる。呼出し時に、項目１００２はＳ
ＦＴ入口を検索する。ＳＦＴ入口及びハンドルは、両方
共ＤｏｓＯｐｅｎにより設定される。次いで、ＴＣＢＴ
ｈｉｓＦＳＣが表示のように設定される。次に、項目１
００４において、ＦＳＣが指示するファイルシステムの
適合ＦＳＤワーカが呼び出される。次いで、項目１００
６は、項目１０１６を呼び出し、必要に応じて項目１０
１６を呼び出すことにより、呼び出し者すなわちコーラ
ー（ｃａｌｌｅｒ）によりリクエストされたあらゆるＩ
／Ｏを実行する。図２０には、ＦＳＨ Ｄｏ Ｖｏｌ
１０が示されている。項目１１０２において呼出しがな
されると、ｈＶＰＢが使用されて、ドライブ並びに関心
のあるボリュームにどのようなボリュームがあるかを決
定する。次に、デシジョン１１０４は、ドライブにおけ
るボリュームが関心のあるボリュームであるか否かを決
定する。関心のあるボリュームであるときは、項目１１
０６が呼び出されて、デバイスドライバが呼び出されか
つ特定のパラメータでＩ／Ｏを実行する。次にデシジョ
ン１１０８は、作業中にメディアが不確実に移行したか
否かを決定する。不確実に移行していないときには、プ
ロセスは項目１１１４に戻る。デシジョン１１０８が、
メディアは不確実ではないことを決定するときには、制
御は項目１１１２に導かれ、ここでは、ＷｈａｔＶｏｌ
ｕｍｅが呼び出されてメディアが確実なものにされる。
次いで、制御はデシジョン１１０４に戻る。ドライブに
おけるボリュームが関心のあるボリュームに一致しない
ときには、項目１１１０が呼び出されて、ＨａｒｄＥｒ
ｒｏｒが呼び出され、ドライブに正しいドライブを置く
ことをユーザに知らせる。次に制御は上記項目１１１２
に導かれる。付録（Ａｐｐｅｎｄｉｘ）ＩＩからＶＩ
は、設置可能なファイルシステムの資源の一例としてこ
こに包含される。ここで、付録ＩＩは、本発明の教示に
従ってサポートすることが期待されるファイルシステム
の移出インターフェース（ｅｘｐｏｒｔｅｄ ｉｎｔｅ
ｒｆａｃｅｓ）のリストである。付録ＩＩＩは、ファイ
ルシステムを用いることができるカーネルにより移出さ
れるインターフェースのリストである。付録ＩＶは、本
発明に従って構成された設置可能なファイルシステムの
一例の資源コードである。付録Ｖは、付録ＩＶのＦＳＤ
を作るべくＯＳ／２により用いられる定義ファイル（ｄ
ｅｆｉｎｉｔｉｏｎｓ ｆｉｌｅ）のリストである。付
録ＶＩは付録ＩＶのＩＦＳにより使用される構成とパラ
メータを限定しているヘッダーファイルである。付録Ｖ
ＩＩは本発明の高性能ファイルシステムを実現するのに
使用するディスク構成の詳細なリストである。要約し
て、データをボリューム内に編成するための改良型高性
能ファイルシステムを説明した。本発明の原理によれ
ば、第１のディスク フィールドがブートブロックを備
え、この第１のフィールドにつづく第２のフィールドが
スーパーブロックを備え、この第２のフィールドに続く
第３のフィールドはスペアブロックを備え、そして複数
のバンドがデータを記憶するための一連の連続セクタを
含み、各バンドはセクタ使用を示すフリースペースビッ
トマップを含んでいる、ディスクの一連のフィールドに
データを編成する。フリースペースビットマップはバン
ドの始めか終わりにあって、交互のバンドのためのビッ
トマップは相互に隣接している。ブートブロックはボリ
ュームネーム、ボリュームＩ．Ｄ．そしてディスクブー
トストラッププログラムを含んでいる。スーパーブロッ
クはフリースペースビットマップ、バッドブロックリス
ト、ディクショナリブロックバンド、そしてルートディ
クショナリへのポインタを含んでいる。本発明に従って
ファイルとディクショナリとはＦノード構成にアンカー
されている。Ｆノード構成はセクタの続きを指している
複数のポインタを備えている。他の使用や変形は当業者
には自明のことであろう。このような使用や変形は本発
明の思想に含まれるものである。
成されたコンピュータシステム１００が示されている。
このコンピュータシステム１００は、中央処理装置すな
わちマイクロプロセッサ１０２と、ランダムアクセスメ
モリ１０４と、リードオンリメモリ１０６と、マウス１
０８及びキーボード１１０のような入力装置と、ディス
プレイ１１２及びプリンタ１１４のような出力装置と、
フロッピディスクドライブ１１６、ハードディスクドラ
イブ１２０、ＣＤ−ＲＯＭドライブ１２２及びテープド
ライブ１２４等からなる種々の不揮発性記憶装置とを有
している。また、このコンピュータシステム１００は、
ネットワーク１２６と通信できるようになっている。不
揮発性記憶とは、装置の電源を遮断してもデータが消去
されないことをいう。従来のシステムにおいては、オペ
レーティングシステムは、各周辺装置が単一のメディア
形ファイルシステムドライバのみと互換性をもつファイ
ルシステムドライバによりスタティックに構成されてい
る。指定のファイルシステムドライブとの互換性のない
ドライブにメディアが供給されると、メディアは首尾良
くアクセスすることができない。以下に説明するよう
に、本発明は、周辺装置とは独立してかつメディアに関
するデータのフォーマット又は位置についての条件を賦
課することなくして、関連するファイルシステムにメデ
ィアを自動的にマッピングする方法及び手段を提供する
ものである。例えば、フロッピドライブユニット（フロ
ッピディスクドライブ）１１６は、多数のファイルシス
テムに従ってフォーマット化されたボリューム（例え
ば、ＦＡＴファイルシステムに従ってフォーマット化さ
れたボリューム１２８、良く知られたＨｉｇｈ Ｓｉｅ
ｒｒａファイルシステムに従ってフォーマット化された
ボリューム１３２、及びもう１つのファイルシステムに
従ってフォーマット化されたボリューム１３０）に使用
することができる。同様に、ハードディスク（ハードデ
ィスクドライブ）１２０の種々の区分（パーティショ
ン）は、ボリューム１３４、１３６、１３８として表し
た多数のファイルシステムに従ってフォーマット化する
ことができる。同様に、ＣＤ−ＲＯＭドライブ１２２及
びテープシステム（テープドライブ）１２４は、ボリュ
ーム１４０、１４２（これらは、それぞれのファイルシ
ステムに従ってフォーマット化されている）に使用する
ことができる。また、ネットワーク１２６は、サーバ
（該サーバは、それら自体のファイルシステムに従って
作動する）を備えた任意の数のネットワークに接続する
ことができる。コンピュータシステム１００の作動（オ
ペレーション）は、良く知られた多数のオペレーティン
グシステムのうちの任意のオペレーティングシステムに
より調整することができる。しかしながら、本発明は特
に、Ｍｉｃｒｏｓｏｆｔ社により開発されたＯＳ／２オ
ペレーティングシステムに使用するのに適している。本
発明の作動環境（ｏｐｅｒａｔｉｎｇ ｅｎｖｉｒｏｎ
ｍｅｎｔ）の構成が図２に示してある。一般に、アプリ
ケーション１５２は、カーネル１５４により処理される
ファイルシステムのリクエストを発生する。次いで、カ
ーネル１５４は、このリクエストを適当なファイルシス
テムドライバ（ＦＳＤ）１５６〜１７０に導く。任意の
ファイルシステムドライバを、多数のハードウェア装置
と協働させることができる。例えば、ボリューム１７
２、１７４についてファイルシステム作動を行う場合に
は、Ｈｉｇｈ Ｓｉｅｒｒａファイルシステム１５６を
ＣＤ−ＲＯＭプレーヤ（ＣＤ−ＲＯＭドライブ）１２２
及びディスクドライブ１１６に使用することができる。
同様に、ＦＡＴファイルシステム１６０及びＨＰＦＳフ
ァイルシステム１６２の両者は、ボリューム１７６、１
７８（これらの各々は、ハードディスク１２０にある）
についてのファイルシステム作動を行うのに使用するこ
とができる。ボリューム１８０についてファイルシステ
ム作動を行う場合には、ディスクドライブ１１６にファ
イルシステムドライバを使用することができる。従っ
て、本発明によれば、ファイルシステムの形式及びフォ
ーマットの如何に拘わらず、適当なファイルシステムに
不確実メディアを自動的にかつダイナミックにマッピン
グする方法及び手段が提供される。図３は、従来技術に
よるＭＳ−ＤＯＳオペレーティングシステムのファイル
システム構成を示すものである。ＭＳ−ＤＯＳオペレー
ティングシステム２００においては、オペレーティング
システムのカーネル２０４内にＦＡＴファイルシステム
２０２が埋設されている。このＦＡＴファイルシステム
２０２はオペレーティングシステムのカーネル２０４内
に一体化されているため、変更（モディファイ）するこ
とは困難である。また、付加的なファイルシステムが必
要な場合には、オペレーティングシステムのカーネル２
０４を書き替えてそれらのファイルシステムに適合でき
るようにしなければならない。本発明によれば、図４に
示すシステム技術により上記問題点を解決することがで
きる。本発明のコンピュータシステム１００において
も、ＯＳ／２カーネル２５２内には、ＦＡＴファイルシ
ステム２０２が埋設されている。しかしながら、本発明
によれば、オペレーティングシステムのカーネル２５２
に対して外部装置であるＦＡＴファイルシステムドライ
バ２５４、２５６、２５８をダイナミックに取り付ける
方法及び手段が提供される。図面には、設置可能な３つ
のファイルシステムドライバを備えたシステム２５０が
示されているが、実際には、本発明は、ファイルシステ
ムドライバの数に制限されることはない。設置可能（ｉ
ｎｓｔａｌｌａｂｌｅ）なファイルシステムドライバ
（ｆｉｌｅｓｙｓｔｅｍ ｄｒｉｖｅｒ、「ＦＳＤ」）
は、多くの点でデバイスドライバに類似している。ＦＳ
Ｄは、ダイナミックリンクライブラリ（ｄｙｎａｍｉｃ
−ｌｉｎｋ ｌｉｂｒａｒｙ、「ＤＬＬ」、一般には、
ＳＹＳ又はＩＦＳエクステンションを備えている））の
ように構成されたファイルのディスク上に存在し、ＣＯ
ＮＦＩＧ．ＳＹＳファイルにおけるＩＦＳ＝ステートメ
ント（ｓｔａｔｅｍｅｎｔｓ）によるシステムの初期化
中にローディングされる。ＩＦＳ＝宣言（ｄｉｒｅｃｔ
ｉｖｅｓ）は、それらが出合う命令において処理され、
また、デバイスドライバについてＤＥＶＩＣＥ＝文（ｓ
ｔａｔｅｍｅｎｔｓ）の命令に対して感応する。これに
より、ユーザが、非標準デバイス用のデバイスドライバ
をローディングし、該デバイスのボリュームからファイ
ルシステムドライバをローディングすること等が可能に
なる。一旦ＦＳＤが設置され且つ初期化されると、カー
ネルは、ファイルの開放、読取り、書込み、シーク（ｓ
ｅｅｋｓ）、閉鎖等についての論理的リクエスト（ｌｏ
ｇｉｃａｌ ｒｅｑｕｅｓｔ）の言語で、ＦＳＤで通信
する。ＦＳＤは、ボリュームそれ自体に見出される制御
構成及びテーブルを用いて、これらのリクエストをセク
タ読取り（ｓｅｃｔｏｒ ｒｅａｄｓ）用のリクエスト
に翻訳し、かつ、ファイルシステムヘルパ（Ｆｉｌｅ
Ｓｙｓｔｅｍ Ｈｅｌｐｅｒｓ、「ＦｓＨｌｐｓ」）と
呼ばれる特別なカーネル入口点を呼び出すことができる
書込みを行う。カーネルは、セクタＩ／Ｏに対するデマ
ンドを適当なデバイスドライバに導き、かつその結果を
ＦＳＤに戻す。ボリュームをＦＳＤｓ（複数のＦＳＤ）
と結合させるべくオペレーティングシステムにより用い
られる手順は、ダイナミックボリュームマウンティング
（ｄａｙｎａｍｉｃ ｖｏｌｕｍｅ ｍｏｕｎｔｉｎ
ｇ）と呼ばれ、次のように作動する。ボリュームが最初
にアクセスされるとき、或いは、直接アクセスを行うべ
く（例えばＦＯＲＭＡＴオペレーションにより）ボリュ
ームがロックされ次いでアンロックされた後に、オペレ
ーティングシステムのカーネルは、ボリュームからＦＳ
Ｄｓの各々への識別情報を発生し、これは、ＦＳＤがこ
の情報を認識するまで順次行われる。ＦＳＤがボリュー
ムをクレイムすると、ボリュームがマウントされ、ボリ
ュームに対する全ての連続ファイルＩ／Ｏリクエスト
が、ボリュームをクレイムしたＦＳＤに導かれる。この
構成により、従来技術にはない幾つかの利点を得ること
ができる。例えば、不確実メディアがコンピュータシス
テムに与えられる場合に、コンピュータシステムは、利
用できるファイルシステムドライバを走査して、このメ
ディアを認識できるファイルシステムドライバを位置付
けすることができ、これにより、メディアへのファイル
システムドライバの自動マッピングを行うことが可能に
なる。また、オペレーティングシステムのカーネルを変
更する必要なくして、ファイルシステムドライバを更新
することができる。更に、新しい形式の周辺装置が開発
されたときに、既存システムのソフトウェアを混乱させ
ることなく、適当なファイルシステムドライバをオペレ
ーティングシステムに付加することができる。コンピュ
ータシステム１００のより詳細なダイアグラムが図５に
示してある。コンピュータシステム１００は、アプリケ
ーションプログラム３０２とディスク装置３０４のよう
なデータ記憶装置との間の通信を行うことができるオペ
レーティングシステムのカーネル２５２を有している。
また、このコンピュータシステム１００は、ファイルシ
ステムドライバ２５４〜２５８と関連して作動するデバ
イスドライバ３０６を有している。図面には単一の周辺
装置３０４を備えたコンピュータシステム１００が示さ
れているが、本発明は、任意の数の論理的又は物理的周
辺装置と組み合わせて使用できるものである。作動に際
し、アプリケーションプログラム３０２は、所望の機能
についての入口点を呼び出すことにより、オペレーティ
ングシステムのカーネル２５２に対する論理的ファイル
リクエストを発行する。これらの機能には、ファイルを
開放すること（ＤｏｓＯｐｅｎ）、ファイルを読み取る
こと（ＤｏｓＲｅａｄ）、ファイルに書き込むこと（Ｄ
ｏｓＷｒｉｔｅ）等のリクエストを含めることができ
る。オペレーティングシステムのカーネル２５２は、こ
れらのリクエストを、ファイルを保持（ホールディン
グ）する特定のボリュームについての適当なファイルシ
ステムドライバ２５４〜２５８に導く。次に、適当な設
置可能なファイルシステムドライバが、論理的ファイル
リクエストを、指定メディアの論理的セクタの読取り及
び書込みのためのリクエストに翻訳し、かつオペレーテ
ィングシステムのカーネルのファイルシステムヘルパ３
０８を呼び出して、これらのリクエストを適当なデバイ
スドライバ３０６に導く。ファイルシステムヘルパ（Ｆ
ｓＨｌｐｓ）３０８については、以下により詳細に説明
する。デバイスドライバ３０６は、オペレーティングシ
ステムのカーネルからの論理的セクタリクエストを、特
定の物理ユニット（すなわち、メディアのシリンダ、ヘ
ッド及びセクタ）についてのリクエストに変形し、か
つ、ディスク装置にコマンドを発行して、ディスクメデ
ィアとランダムアクセスメモリ３１０との間にデータを
伝達する。次に、物理装置を特定のファイルシステムに
マッピングすることについて以下に詳細に説明する。Ｍ
Ｓ−ＤＯＳ環境（ＭＳ−ＤＯＳ ｅｎｖｉｒｏｎｍｅｎ
ｔ）においては、フロッピディスクはボリュームと呼ば
れる。固定ディスク（又はハードディスク）は、多数の
ボリュームに区分することができる。このターミノロジ
が、本発明に首尾よく適用されている。簡単に言えば、
コンピュータシステムが最初にブート（ｂｏｏｔ）され
るとき、ボリュームが最初にアクセスされるとき、又は
コンピュータシステムが、ディスク装置３０４内に不確
実メディアが存在することを決定するときにはいつで
も、コンピュータシステムは、ファイルシステムドライ
バのリンクされたリストにおける最初のファイルシステ
ムドライバを試験する。ファイルシステムドライバがデ
ィスク装置にローディングされたボリュームを認識する
場合には、ファイルシステムドライバがマウントされ
る。そうでない場合には、コンピュータシステムは、メ
ディアを認識するファイルシステムドライバが位置付け
されるまで、利用できるファイルシステムドライバを連
続的にボーリングする。関心をもつメディアを認識する
設置可能なファイルシステムドライバが全く見出されな
い場合には、省略時ファイルシステムドライバがマウン
トされる。本発明の好ましい実施例においては、省略時
ファイルシステムは、上記のＦＡＴファイルシステムで
ある。不確実メディアは、幾つかの方法により検出する
ことができる。ディスク装置には機械的なラッチ機構が
設けられており、該ラッチ機構は、ディスクがディスク
装置から取り出されるとき又はディスク装置に装填され
るときに作動する。一般にラッチ機構は、ドライブの次
の作動によりドアが開放されたことを示すように機能す
る。デバイスドライバがこの表示を受け取ると、エラー
不確実メディア（ＥＲＲＯＲ＿ＵＮＣＥＲＴＡＩＮ Ｍ
ＥＤＩＡ）がオペレーティングシステムに戻される。機
械的なラッチ機構がないシステムにおいては、所定時間
より短い時間内にメディアを変更できないと考えられ
る。本発明の好ましい実施例においては、この時間は２
秒であるこ考えられる。従って、所定時間以上の時間を
かけても特定のボリュームがアクセスされない場合に
は、このメディアは不確実であると推定される。図６
は、ＦＡＴファイルシステムのディスクフォーマットの
ダイアグラムである。ＦＡＴファイルシステムは、ＭＳ
−ＤＯＳオペレーティングシステムの初期から該ＭＳ−
ＤＯＳオペレーティングシステムに使用されている。Ｆ
ＡＴファイルシステムについての詳細な説明が、Ｄａｎ
ｃａｎ著「アドバンスＭＳ ＤＯＳプログラミング
（“Ａｄｖａｎｃｅ ＭＳ ＤＯＳ Ｐｒｏｇｒａｍｍ
ｉｎｇ”）」（Ｍｉｃｒｏｓｏｆｔ Ｐｒｅｓｓ社刊、
１９８６、１９８８）においてなされている。ＦＡＴフ
ァイルシステムは、ＦＡＴファイルシステムは、ファイ
ル割当てテーブル（Ｆｉｌｅ Ａｌｌｏｃａｔｉｏｎ
Ｔａｂｌｅ）を中心題目としている。各論理的ボリュー
ムはそれ自体のＦＡＴと関連していて、２つの重要な機
能を有している。すなわち、各論理的ボリュームは、割
当てユニット（ａｌｌｏｃａｔｉｏｎｕｎｉｔｓ）のリ
ンクされたリストの形態をなすボリュームに関する各フ
ァイルについての割当て情報（ａｌｌｏｃａｔｉｏｎ
ｉｎｆｏｒｍａｔｉｏｎ）を収容していて、その割当て
ユニットには、創出（又は拡大）されているファイルへ
の割当て（代入、ａｓｓｉｇｎｍｅｎｔ）がないことを
表示する。ＦＡＴファイルシステムに従ってディスクが
フォーマット化されると、ブートセクタ（ｂｏｏｔ ｓ
ｅｃｔｅｒ）がセクタゼロと書き込まれる。ファイル割
当てテーブルの後にはルートディレクトリ（ｒｏｏｔ
ｄｉｒｅｃｔｏｒｙ）が続き、このルートディレクトリ
の後にはボリュームファイルが続く。ブートセクタに
は、ブートパラメータブロックすなわちＢＰＢと呼ばれ
る、或る領域におけるボリュームに関する種々の記述情
報（ｄｅｓｃｒｉｐｔｉｖｅ ｉｎｆｏｒｍａｔｉｏ
ｎ）、ドライブの数及びボリュームＩ．Ｄ．のような情
報、及びブートストラップルーチン（ｂｏｏｔｓｔｒａ
ｐ ｒｏｕｔｉｎｅ）が収容されている。ファイル割当
てテーブルは、ディスクについての割当て可能なクラス
タ（これらのクラスタは、セクタを２乗したものであ
る）に直接相当するフィールド（欄）に区分される。一
般に、これらのフィールドは１６ビットの幅を有してい
る。最初にリザーブされたＦＡＴ入口には、ＢＰＢにお
いても見出すことができるメディア記述バイト（ｍｅｄ
ｉａ ｄｅｓｃｒｉｐｔｏｒ ｂｙｔｅ）のコピーが収
容されている。リザーブされた残余のフィールドにはＯ
ＦＰＨが収容されている。残余のＦＡＴ入口には、それ
らの相当ディスククラスタ（ｃｏｒｒｅｓｐｏｎｄｉｎ
ｇ ｄｉｓｋ ｃｌｕｓｔｅｒｓ）の使用が記述され
る。ディレクトリの各ファイルの入口には、これらのフ
ァイル（該ファイルは、ＦＡＴへの入口点として使用さ
れる）に割り当てられる最初のクラスタの数が収容され
る。入口点から、各ＦＡＴスロット（ＦＡＴ ｓｌｏ
ｔ）が、最終クラスタマークに出合うまで、ファイル内
の次のクラスタの番号を収容する。また、ＦＡＴファイ
ルシステムには、読取りエラー等によるＦＡＴのセクタ
へのアクセスが失敗した場合に用いることができる最初
のファイル割当てテーブルの複製を維持する機能をオプ
ションとして設けることができる。ファイル割当てテー
ブルの後には、ルートディフレクトリが続く。このルー
トディレクトリは、ファイル、他のディレクトリ、及び
オプションとしてのボリュームラベルを記述する３２バ
イトの入口を収容している。ルートディレクトリの後の
残余のボリュームは、クラスタのプールとして見ること
ができるファイル領域（各ファイル領域には１つ以上の
論理的セクタが収容されている）として知られている。
各クラスタは、ＦＡＴの対応入口（該入口には、ＦＡＴ
の現在使用、すなわち、利用できること、リザーブされ
ていること、ファイルに割り当てられていること、又は
使用できないことが記述されている）を備えている。Ｆ
ＡＴファイルシステムは、１Ｍｂ以下のボリュームで優
れた性能を得ることができる。しかしながら、ボリュー
ムのサイズが１Ｍｂを越えると、ＦＡＴファイルシステ
ムの性能は急激に低下する。容易に入手可能なハードデ
ィスクのサイズは急激に増大しているため、このことは
重要な問題となっている。ボリュームが１Ｍｂ以下の場
合には、ＦＡＴは、いつでもランダムアクセスメモリ内
に保持される程充分に小さく、従って、ファイルのいか
なる部分にも非常に高速のランダムアクセスを行うこと
ができる。しかしながら、ハードディスク又は固定ディ
スクに適用した場合には、ＦＡＴは大き過ぎてメモリに
保持できなくなり、かつ細分してメモリ内にページ付け
しなければならない。このために多くの余分のディスク
ヘッド運動が必要になり、コンピュータシステムのスル
ープットを低下させている。また、ディスクの空きスペ
ース（ｆｒｅｅ ｓｐａｃｅ）についての情報が、ＦＡ
Ｔの多数のセクタを横切って分散されるため、連続的に
ファイルスペースを割り当てることは実際的でない。こ
のため：ファイルが細分化され、コンピュータシステム
のスループットが更に低下される。また、ハードディス
クに比較的大型のクラスタを用いるため、無駄なスペー
スが非常に大きくなる。図７〜図１４には、設置可能な
ファイルシステムの１つの場合のディスクフォーマット
を示す一連のダイアグラムが示されている。このファイ
ルシステムは、高性能ファイルシステム（Ｈｉｇｈ ｐ
ｅｒｆｏｒｍａｎｃｅ ｆｉｌｅ ｓｙｓｔｅｍ，ＨＰ
ＦＳ）と呼ばれているものである。本発明の高性能ファ
イルシステムは、ＦＡＴファイルシステムについての上
記問題を解消でき、かつあらゆる形式のディスクメディ
アについて優れた性能を発揮できるものである。図７に
示すように、ＨＰＦＳボリュームは、前に形成されたＦ
ＡＴパーティション形の側面に沿って固定ディスク上に
設けることができる。ＨＰＦＳボリュームは、５１２バ
イトのセクタサイズを使用しており、２１９９Ｇｂ（２
３２のセクタ）の最大サイズを有している。ＨＰＦＳは
固定ディスクに使用することを主として設計されている
が、実際上、あらゆる形式のディスクメディアとの互換
性を有している。ＨＰＦＳボリュームは、固定された構
成が殆ど必要とされない。ブートブロック５０２にはボ
リューム（８Ｋｂ）のセクタ０〜１５が割り当てられ、
該セクタ０〜１５は、ボリュームのネームフィールド
（名前欄）５０４、３２ビットボリュームの１Ｄフィー
ルド５０６、ＢＩＯＳパラメータブロック５０８、ディ
スクブートストラッププログラム５１０を収容してい
る。ディスクブートストラッププログラム５１０は、オ
ペレーティングシステムファイルが見出される限りは、
これらのオペレーティングシステムファイルの位置付け
及び読取りを行う限定モードで使用することができる。
ブートブロック（ＢｏｏｔＢｌｏｃｋ）５０２の後に
は、スーパーブロック（ＳｕｐｅｒＢｌｏｃｋ）５１２
及びスペアブロック（ＳｐａｒｅＢｌｏｃｋ）５１４が
続いている。スーパーブロック５１２は、ディスクメイ
ンテナンスユーティリティによって変更されるに過ぎな
い。スーパーブロック５１２は、空きスペースのビット
マップを指すポインタ５１６、バットブロックリスト５
１８、ディレクトリブロックバンドを指すポインタ５２
０、ルートディレクトリを指すポインタ５２２を収容し
ている。更にスーパーブロック５１２は、デート（日付
け）を備えたデートフィールド（日付け欄）５２４を収
容しており、ボリュームはＣＨＫＤＳＫにより最終チェ
ック及び修復がなされる。ＣＨＫＤＳＫは、ディスクの
悪い部分を検出しかつカタログするための良く知られた
ＯＳ／２ディスクユーティリティである。スペアブロッ
ク５１４は種々のフラグ及びポインタを収容しており、
これらについては以下に詳述する。スペアブロック５１
４は、コンピュータシステムが実行されるときに変更さ
れる。残余のボリュームは、ファイルの記憶に使用され
る８Ｍｂバンド（例えば、バンド５１６〜５２２）に区
分される。図７には４つの８Ｍｂバンドが示されている
が、ＨＰＦＳは非常に多数のバンドを得ることがきる。
各バンドには、それ自体の空きスペースビットマップ
（例えば、ビットマップ５２４〜５３４参照）が設けら
れている。空きスペースビットマップの各ビットは、セ
クタを表している。セクタが使用されている場合にはビ
ットは０であり、セクタが使用可能（アベイラブル）で
あるときには、ビットは１である。ビットマップは、バ
ンドのヘッド又はテールに位置付けされるため、２つの
ビットマップは交互のバンドの間に隣接している。ビッ
トマップのバンドサイズは、任意のサイズのファイルを
収容できるように変更できるけれども、上記構成によ
り、１６Ｍｂになるようにファイルに割り当てることが
できる最大の連続空きスペースを得ることができる。デ
ィスクのシークセンタにおいて（又はシークセンタに向
かって）位置付けされた１つのバンドは、ディレクトリ
ブロックバンドと呼ばれ、後述するような特別な処理を
受ける。ＨＰＦＳの全てのファイル又はディレクトリ
は、図８及び図９に示すＦｎｏｄｅと呼ばれている基本
ファイルシステムの目的（オブジェクト）にアンカーさ
れている。Ｆｎｏｄｅ５３０は、ファイル又はディレク
トリに割り当てられた最初のセクタすなわち第１セクタ
であり、スーパーブロック５０４におけるフィールド５
２２により指示されている。各Ｆｎｏｄｅ５３０は単一
のセクタを占拠し、かつ、図８に示すように、ファイル
システムにより内的に用いられる制御及びアクセス情報
フィールド５４０、拡大属性（ｅｘｔｅｎｄｅｄ ａｔ
ｔｒｉｂｕｔｅ、「ＥＡ」）、及びアクセス制御リスト
（ａｃｃｅｓｓ ｃｏｎｔｒｏｌ ｌｉｓｔｓ，「ＡＣ
Ｌｓ」）を記憶する領域５４２、関連するファイル又は
ディレクトリのネームの長さ及び最初の１５文字を表示
したい場合にはそのためのフィールド５４４、及び割当
て構成５４６を収容している。Ｆｎｏｄｅは、これを代
表するファイル又はディレクトリの近くに常に記憶され
ている。図９に示す割当て構成５４６は、ファイル又は
ディレクトリの連続性のサイズ及び度合に基づいて幾つ
かの形態をとる。本発明のＨＰＦＳは、１つ以上の連続
セクタの１つ以上の実行（ｒｕｎｓ）又はエクステント
の割当てとして、ファイルをビュー（ｖｉｅｗｓ）して
いる。各実行は、１対の二重ワード、すなわち、セクタ
における３２ビットのスタートセクタ数及び３２ビット
の長さ（この長さは、実行長さエンコーディングと呼ば
れている）により記号化される。アプリケーションプロ
グラムの観点からすると、エクステントは目で見ること
はできない。すなわち、ファイルはバイトの継ぎ目のな
い流れであると考えることができる。Ｆｎｏｄｅにおけ
る割当て情報にリザーブされたスペースは、各１６Ｍｂ
までのセクタの８回の実行と同数のポインタを保持する
ことができる。従って、高度連続サイズのかなり小さな
ファイルを、Ｆｎｏｄｅの中に完全に記述することがで
きる。ＨＰＦＳは、Ｆｎｏｄｅにとっては大き過ぎるか
細分され過ぎているファイルの位置を示す新しい方法を
採用しており、８回以上の実行を有している、Ｆｎｏｄ
ｅの割当ては、割当てセクタのＢ＋ツリー（木）のルー
ト（根）となり、このルートには、図１０に示すよう
に、ファイルのセクタ実行を指す実際のポインタが収容
されている。Ｂ＋ツリー及びＢ−ツリーの概念について
は後で詳述する。Ｆｎｏｄｅのルートは、１２のエレメ
ントのためのルームを有している。各割当てセクタは、
種々のセクタ情報に加えて、セクタ実行を指す４０個程
のポインタを収容することができる。従って、本発明の
好ましい実施例においては、２レベル割当てのＢ＋ツリ
ー（ｔｗｏ ｌｅｖｅｌ ａｌｌｏｃａｔｉｏｎｓ Ｂ
＋Ｔｒｅｅ）が、７．６８Ｇｂ（１２＊４０＊１６Ｍ
ｂ）の論理的最大サイズを持つ４８０（１２＊４０）回
のセクタ実行のファイルを記述することができる。これ
と異なり、高度に細分化されたファイルを記述するには
２レベル割当てのＢ＋ツリーが充分でない場合には、Ｈ
ＰＦＳファイルシステムが、ツリーに必要なだけの付加
的レベルを導入する。中間レベルにおける割当てセクタ
は、６０個程の内部（端部ではない）Ｂ＋ツリーノード
を保持することができ、このことは、この構成の記述能
力が極めて大きな数に急速に成長することを意味してい
る。例えば、３レベル割当てＢ＋ツリーは、２８，８０
０（１２＊６０＊４０）回のセクタ実行を記述すること
ができる。割当てセクタの実行長さエンコーディング
（ｒｕｎ−ｌｅｎｇｔｈ ｅｎｃｏｄｉｎｇｓ）及びＢ
＋ツリーは、ファイルのサイズ及び位置を充分に特定で
きるメモリであり、かつ従来技術に比べ幾つかの優れた
長所を有している。セクタ数への論理的ファイルオフセ
ットの翻訳は極めて高速に行われる。すなわち、ファイ
ルシステムは、正しい範囲が見出されるまで実行サイズ
を要約し、実行ポインタ（ｒｕｎ ｐｏｉｎｔｅｒｓ）
のリスト（すなわちリストのＢ＋ツリー）を単に横切る
だけである。そのとき、簡単な計算を行うことにより、
実行の中でセクタを識別することができる。また、新た
に割り当てられたセクタがファイルの前の最終セクタと
連続している場合には、実行長さエンコーディングによ
って、ファイルを論理的に拡大することが極めて簡単に
なる。このファイルシステムは、ファイルの最終実行ポ
インタのサイズ二重ワード（ｓｉｚｅ ｄｏｕｂｌｅ
ｎｏｒｄ）を単に増大させるだけであり、適当な空きス
ペースのビットマップにおけるセクタのビットをクリア
するように構成されている。ファイルと同様に、ディレ
クトリはＦｎｏｄｅｓにアンカーされる。ルートディレ
クトリ（ｒｏｏｔ ｄｉｒｅｃｔｏｒｙ）についてのＦ
ｎｏｄｅを指すポインタは、スーパーブロック５１２に
おいて見出すことができる。図１１は、本発明によるデ
ィレクトリ構成を示すものであり、ここにはディレクト
リＦｎｏｄｅ５５０が示されている。ルート以外のディ
レクトリについてのＦｎｏｄｅは、それらの親ディレク
トリ（ｐａｒｅｎｔ ｄｉｒｅｃｔｏｒｉｅｓ）におけ
るサブディレクトリ入口を通って到達する。ディレクト
リは、ディスク上に４つの連続セクタ（ｃｏｎｓｅｃｕ
ｔｉｖｅｓｅｃｔｏｒｓ）として割り当てられる２Ｋｂ
のディレクトリブロックから構成されていて、任意のサ
イズに成長することができる。例えば、ディレクトリブ
ロック５５２、５５４、５５６を参照されたい。このフ
ァイルシステムは、ディスクのシークセンタ又はその近
くに位置付けされたディレクトリバンドにディレクトリ
ブロックを割り当てることを試みている。ディレクトリ
バンドが満たされると、スペースが利用できる限り、デ
ィレクトリブロックが割り当てられる。２Ｋｂの各ディ
レクトリブロックには、１つから多数のディレクトリ入
口を設けることができる。例えば、入口５５８〜５６８
を参照されたい。ディレクトリ入口には幾つかのフィー
ルド（欄）が設けられ、これらのフィールドには、図１
１に示すように、時間及び日付スタンプのためのフィー
ルド５７０と、Ｆｎｏｄｅポインタを収容するフィール
ド５７２と、ディスクメインテナンスプログラム（この
プログラムは良く知られたものである）による使用がで
きるようにするための用法カウントフィールド（ｕｓａ
ｇｅ ｃｏｕｎｔ ｆｉｅｌｄ）５７４と、ファイルの
長さすなわちディレクトリネームを収容するフィールド
５７６と、ネーム自体のフィールド５７８と、Ｂ−ツリ
ーポインタを収容するフィールド５８０とが含まれてい
る。各ディレクトリ入口は、入口の長さを含んでいるワ
ード５８２で始まる。これにより、各入口の終時におけ
るフレックススペースの可変量が与えられる。この可変
量は、ファイルシステムの特別なバージョンに使用でき
るようにし、かつディレクトリブロックを極めて迅速に
横切らせることを可能にする。ディレクトリブロックの
入口の数は、ネームの長さによって変化する。平均的な
ファイルネームの長さが１３文字であるときには、平均
ディレクトリブロックはほぼ４０個の入口を保持するで
あろう。ディレクトリブロックの入口は、それらのネー
ムフィールド（名前欄）の２進字句順序（ｂｉｎａｒｙ
ｌｅｘｉｃａｌ ｏｒｄｅｒ）により分類される。最
終入口は、ブロックの終了を印すダミーレコードであ
る。ディレクトリが大きくなり過ぎて１つのブロック内
に記憶されなくなった場合には、Ｂ−ツリーとして編成
される２Ｋｂブロックを付加することによりサイズを大
きくできる。特定のネームをサーチする場合には、ファ
イルシステムが一致を見出すか、目的とするネームより
も字句的に多いネームを見出すまで、ファイルシステム
がディレクトリブロックを横行する。後者の場合、ファ
イルシステムが、入口からＢ−ツリーのポインタを抽出
する。このポインタがどのサーチフィールドをも指示し
ない場合には、ファイルシステムは、ツリーにおける次
のディレクトリブロックを次のポインタにより指示さ
せ、サーチを続行する。ブロック当り４０個の入口があ
るものと仮定すれば、ディレクトリブロックの２レベル
ツリーは１，６４０個のディレクトリ入口を保持でき、
３レベルツリーは６５，６４０個の入口を保持すること
ができる。換言すれば、最大限３つのディスクアクセス
を備えた一般的な６５，６４０個のファイルにおいて、
特定のファイルを見出すことができる（又は、それが存
在しないことを示すことができる）。ディスクアクセス
の実際の数は、キャッシュコンテンツ（ｃａｃｈｅ ｃ
ｏｎｔｅｎｔｓ）及びディレクトリブロックのＢ−ツリ
ーのファイルネームの位置に基づいて定められる。これ
は、最悪の場合４，０００個のセクタを読み取って、同
数のファイルを収容しているディレクトリにファイルが
存在するか否かを画定しなければならないＦＡＴファイ
ルシステムに対して顕著な改善を与えるものである。Ｈ
ＰＦＳのＢ−ツリーディレクトリ構成は、開放作業及び
見出し作業に関するその効果を超える興味ある含意（ｉ
ｍｐｌｉｃａｔｉｏｎｓ）を有している。ディレクトリ
ブロックを付加（又は除去）するか、或いはネームが或
るブロックから他のブロックに移動されてツリーのバラ
ンスを保つとき、ファイルの創出、リネーミング又は削
除により、複雑な作業のカスケードを生じさせるかもし
れない。実際、ファイル自体が成長することはないけれ
ども、リネーム作業によってディスクスペースの不足を
きたすであろう。この問題を回避するには、ＨＰＦＳ
が、ディレクトリの緊急時に引き出すことができる空き
ブロックの小さなプールをリザーブし、このプールを指
すポインタがスペアブロックに記憶されるように構成す
るのが好ましい。ファイル属性は、ファイルの明白な記
憶領域の外でオペレーティングシステムにより維持され
るファイルについての情報である。本発明のＨＰＦＳ
は、拡大属性（Ｅｘｔｅｎｄｅｄ Ａｔｔｒｉｂｕｔｅ
ｓ，「ＥＡｓ」を支持し、ネームバリューの形態をと
る。但し、バリュー部分は、ゼロで終わる記号列（ｎｕ
ｌｌ−ｔｅｒｍｉｎａｔｅｄｓｔｒｉｎｇ，「ＡＳＣＩ
ＩＺ」）でもよいし２進データでもよい点を除く。本発
明の好ましい実施例においては、各ファイル又はディレ
クトリは、これに取り付けられたＥＡｓの６４Ｋｂの最
大値をとることができる。但し、この制限は容易に変更
することができる。ＥＡｓの記憶方法は変えることがで
きる。所与のファイル又はディレクトリと関連するＥＡ
ｓが充分に小さい場合には、これらのＥＡｓはＦｎｏｄ
ｅに記憶されるであろう。また、ＥＡｓの全体のサイズ
が非常に大きいときには、これらのＥＡｓはセクタ実行
においてＦｎｏｄｅｓの外に記憶され、割当てセクタの
Ｂ＋ツリーが創出されて実行が記述される。単一のＥＡ
が非常に大きい場合には、該ＥＡはＦｎｏｄｅの外に押
し出され、該ＥＡ自体のＢ＋ツリー内に押し込まれる。
本発明は、アプリケーションプログラムがファイルの拡
大属性（ＥｘｔｅｎｄｅｄＡｔｔｒｉｂｕｔｅｓ）を走
査することを可能にするＯＳ／２カーネルのＡＰＩ機
能、すなわち、ＤＯＳＱＦｉｌｅＩｎｆｏ及びＤｏｓＳ
ｅｔＦｉｌｅＩｎｆｏを改善することができる。また、
本発明によれば、任意のパスネーム（パス名）と関連す
るＥＡｓの読取り及び書込みに使用できる２つの新たな
機能、すなわちＤＯＳＱＰａｔｈＩｎｆｏ及びＤＯｓＳ
ｅｌＰａｔｈＩｎｆｏを得ることができる。アプリケー
ションプログラムは、特定のＥＡ（これは、一致させる
べきネームを供給する）のバリューを要求するか、ファ
イル又はディレクトリについての全てのＥＡｓを一度に
得ることができる。ＥＡｓの支持により、目的にかなっ
たアプリケーションプログラムの使用が容易になる。フ
ァイルを所有するアプリケーションのネームから、従属
ファイルのネーム、アイコン及び実行コード（ｅｘｅｃ
ｕｔａｂｌｅ ｃｏｄｅ）に至る殆ど全ての形式の情報
をＥＡｓに記憶させることができる。ＨＰＦＳは、多レ
ベルでのディスクスループットの潜在的ボトルネックを
アタックする。性能を向上させるため、ＨＰＦＳは、進
歩したデータ構成、連続セクタ割当て、インテリジェン
トキャッシング、読取りヘッド、及びデファード書込み
（ｄｅｆｅｒｒｅｄ ｗｒｉｔｅｓ）を使用している。
最初に、ＨＰＦＳは、そのデータ構成、すなわち、ファ
イルネーム、ディレクトリネーム、ファイル又はディレ
クトリに割り当てられたセクタのリストへの高速ランダ
ムアクセスが行えるようにした複雑なデータ構成（Ｂ−
ツリー及びＢ＋ツリー）、及び適当なサイズの空きスペ
ースのチャンクを位置付けできるようにする簡単でコン
パクトなデータ構成（ビットマップ）をタスクに一致さ
せる。これらのデータ構成を操作するルーチンは、アセ
ンブラ言語で記載するのが好ましい。ＨＰＦＳの主目的
は、可能な限り、連続セクタをファイルに割り当てるこ
とである。ディスクの読取り／書込みヘッドを或るトラ
ックから他のトラックに移動させるのに要する時間は、
可能性のある他の遅延よりも遙かに重大であり、このた
め、ＨＰＦＳは、ファイルスペースを連続的に割り当て
ることにより、及びＦｎｏｄｅ及び該Ｆｎｏｄｅが制御
する事柄の近くの空きスペースビットマップのような制
御構成を維持することにより、このようなヘッド運動を
回避するか最小限にする。高度の連続的なファイルはま
た、多くのセクタに対し一度に要求されるディスクドラ
イバのリクエストを、ファイルシステムによって少なく
することを補助し、ディスクドライバが、ディスクコン
トローラの多セクタ移送能力を活用できるようにし、か
つ、修理すべきディスクの完全な中断数を低減させるこ
とができる。多数のファイルを同時に更新させるマルチ
タスキングオペレーティングシステムにおいてファイル
が細分化されないように維持することは、従来技術には
見られない特徴である。ＨＰＦＳが用いている１つの方
法（手順）は、新しく創出されたファイルを別々のバン
ドのディスクを横切って分散させ、できるならば、セク
タが拡大されるときファイルに割り当てられるセクタが
インターリーブされないようにすることである。他の方
法は、ファイルを拡大しなければならない度毎に、連続
スペースの４Ｋｂをファイルに予め割り当てて、ファイ
ルを閉じるときに全ての過剰のスペースを戻す方法であ
る。アプリケーションが、新しいファイルの最終的サイ
ズを予め知ることができるならば、ＨＰＦＳがファイル
を創出するときに、最初のファイル割当てを特定化する
ことにより、ＨＰＦＳを補助することができるであろ
う。そうすれば、システムは全ての空きスペースビット
マップをサーチして、ファイルを充分に保持できる連続
セクタの実行を見出すことができるであろう。このこと
に失敗した場合には、システムは、ファイルのサイズの
１／２である２ラウンドをサーチし、以下このことが繰
り返される。ＨＰＦＳは、幾つかの異なる種類のキャッ
シングに頼って、ＨＰＦＳが要求する物理ディスク転送
の数を最小限にしている。ＨＰＦＳは、ＦＡＴファイル
システムが行ったようにして、セクタのキャッシングを
行う。しかしながら、ＦＡＴファイルシステムとは異な
り、ＨＰＦＳは非常に大きなキャッシユを効率良く管理
し、セクタキャッシングを、パーハンドルベース（ｐｅ
ｒ−ｈａｎｄｌｅ ｂａｓｉｓ）で、ファイルが用いら
れる方法に調節するようになっている。また、ＨＰＦＳ
は、パスネーム、ディレクトリ、トランスフォーミング
ディスクディレクトリ入口を、記憶表現（ｍｅｍｏｒｙ
ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）におけるよりコンパ
クトで効率の良いものにキャッシングする。性能を向上
させるべくＨＰＦＳが用いられているもう１つの技術
は、プログラムが必要とすると考えられるデータを予め
読み取ることである。例えば、ファイルが開かれると
き、ファイルシステムが、Ｆｎｏｄｅ及びファイルの内
容の最初の幾つかのセクタを予めよみとりかつキャッシ
ングする。ファイルが、該ファイル注の実行プログラム
（Ｅｘｅｃｕｔａｂｌｅ Ｐｒｏｇｒａｍ）又はヒスト
リー情報である場合には、Ｆｎｏｄｅは、全ファイルを
直ちに連続的に読み取ることにより、ファイルの開放作
業が一般的に続けられていることを示す。ファイルシス
テムは、より多くのファイル内容物を用意しかつキャッ
シングする。プログラムが比較的少量の読取りリクエス
トを発行する場合には、ファイルシステムは２Ｋｂのチ
ャングのファイルから絶えずデータを取り出し、過剰の
データをキャッシングする。このキャッシングにより、
殆どの読取り作業が満足できるものになる。本発明のＨ
ＰＦＳは、ＯＳ／２のマルチタスキング能力に基づいた
遅い書込み（ｌａｚｙ ｗｒｉｔｅｓ、デファード書込
み又はライトビハインド（ｗｒｉｔｅ ｂｅｈｉｎｄ）
とも呼ばれている）を頼りにしているところが大きい。
例えば、プログラムがディスク書込みを要求する場合に
は、データはキャッシュ内に置かれ、キャッシュバッフ
ァがダーティとしてフラグされる（すなわち、ディスク
のデータの状態と一致しないことを示す）。ディスクが
アイドル状態になるか、或いはキャッシュがダーティバ
ッファで飽和されると、ファイルシステムは、ダエモン
プロセス（ｄａｅｍｏｎｐｒｏｃｅｓｓ）からのキャプ
ティプスレッド（ｃａｐｔｉｖｅ ｔｈｒｅａｄ）を用
いてバッファをディスクに書き込み、最も古いデータで
スタートする。キャプティブスレッド及びダエモンプロ
セスについては、Ｈａｓｔｉｎｇｓ、その他の著者によ
るテキストシリーズ「マイクロソフト社のＯＳ／２プロ
グラマーズリファレンス（“Ｍｉｃｒｏｓｏｆｔ ＯＳ
／２Ｐｒｏｇｒａｍｍｅｒｓ Ｒｅｆｅｒｅｎｃｅ”」
（１９８９年、Ｍｉｃｒｏｓｏｆｔ Ｐｒｅｓｓ社刊）
において説明されている。一般に、遅い書込みは、プロ
グラムがより高速で実行されることを意味している。な
ぜならば、一般に、プログラムの読取りリクエストは、
書込みリクエストを待機して遅延することなく完了する
からである。繰り返し読み取られるプログラムの場合
は、小さなワーキングセットを変更して書き込むので、
遅い書込みはまた、多くの不必要なすなわち冗長な物理
ディスク書込みを回避することができる。遅い書込みは
それらの或る危険性を有しており、従って本発明は、Ｄ
ｏｓＯｐｅｎに対してＯｐｅｎＭｏｄｅパラメータのラ
イトスルーフラグ（ｗｒｉｔｅ−ｔｈｒｏｕｇｈ ｆｌ
ａｇ）を設定することにより、パーハンドルベース（ｐ
ｅｒ−ｈａｎｄｌｅ ｂａｓｉｓ）上で遅い書込みに打
ち勝ち、ＤｏｓＲｅｆＲｅｓｅｔ機能により、パーハン
ドルベース上のディスクにデータを委託（ｃｏｍｍｉ
ｔ）することができる。ＯＳ／２の現行バージョンにお
いても、ＤｏｓＯｐｅｎ及びＤｏｓＢｕｆＲｅｓｅｔの
両機能を利用することができる。遅い書込み（ｌａｚｙ
ｗｒｉｔｅ）の広範囲な使用により、ＨＰＦＳが、あ
らゆる緊事態の下での書込みエラーから優雅に回復でき
るようになる。例えば、書込みの失敗が知られるときま
でに、アプリケーションは長時間を要する。なぜなら
ば、アプリケーションは、データをディスク記憶装置内
に安全に運び出したという錯覚の下で行われるからであ
る。ディスクアダプタにより戻される「セクタが見つけ
ないエラー（“ｓｅｃｔｏｒ ｎｏｔ ｆｏｕｎｄ”ｅ
ｒｒｏｒ）」のようなエラーは、ハードウェアにより検
出することができる。或いは、そのようなエラーは、デ
ータの書込み後、読取り検証（ｒｅａｄ ａｆｔｅｒ−
ｗｒｉｔｅ ｖｅｒｉｆｉｃａｔｉｏｎ）中、ハードウ
ェアのディスクドライバにより検出される。書込みエラ
ーを取り扱う主要機構は、ホットフィックス（ｈｏｔｆ
ｉｘ）と呼ばれる。エラーが検出されると、ファイルシ
ステムは、リザーブされたネットフィックスプールから
空きブロックを取り出し、該ブロックにデータを書込ん
で、ホットフィックスマップを更新する（ホットフィッ
クスマップとは、単に、一連の対をなす二重ワードのこ
とであり、二重ワードの各対は、そのホットフィックス
交換の番号と関連する番号の悪いセクタを収容してい
る）。次に、ホットフィックスマップのコピーがスペア
ブロックに書き込まれ、ディスク装置に問題があること
をユーザに知らせる警告メッセージがディスプレイされ
る。ファイルシステムがディスクドライバからのセクタ
読取り又は書込みを要求する度毎に、ファンシステム
は、ネットフィックスマップを走査して、悪いセクタの
番号を実際のデータを保持している良いセクタに相当す
る番号に置き換える。ＣＨＫＤＳＫの１つのデューティ
はホットフィックスマップを空にすることである。ホッ
トフィックスマップの各交換ブロックに対し、ＣＨＫＤ
ＳＫは、データを所有するファイルに対する好ましい位
置にある新しいセクタを割り当て、データをホットフィ
ックスブロックから新しい割り当てられたセクタに移動
させ、かつ、ファイルの割当て情報（この情報には、再
バランスしている割当てツリー及び他の精巧な作業が含
まれている）を更新する。次いで、ＣＨＫＤＳＫは、悪
いブロックリストに悪いセクタを付加し、交換セクタを
解放してホットフィックスプールに戻し、ホットフィッ
クスマップからホットフィックス入口を削除し、かつ、
更新したホットフィックスマップをスペアブロックに書
き込む。ＨＰＦＳは、かくＨＰＦＳボリュームのスペア
ブロックにダーティＦＳフラグを維持するＨＰＦＳボリ
ームの全てのファイルが閉じられるとき、キャッシュ内
の全てのダーティバッファが書き込まれるとき、或い
は、ブートボリュームの場合にはシャットダウンが選択
されかつその作業を完了したときに、フラグがクリアさ
れる。ＯＳ／２のブートシーケンス中に、ファイルシス
テムが各ＨＰＦＳ上のダーティＦＳフラグを検査して、
フラグが設定されている場合には、ＣＨＫＤＳＫが実行
されるまでブートボリュームには更にアクセスできない
ようにする。ブートボリュームにダーティＦＳフラグが
設定されている場合には、システムは自動的にＣＨＫＤ
ＳＫを実行する。スーパーブロック又はルートディレク
トリの損失というような眞に重大な事故には、最も成功
の可能性のあるデータ回復を与えることができるように
ＨＰＦＳが設計されている。Ｆｎｏｄｅ、割当てセクタ
及びディレクトリブロックを備えた殆ど全ての形式の重
要なファイル目的（オブジェクト）が、その親及び子の
両方に二重にリンクされており、かつ、ユニークな３２
ビットのサインを収容している。Ｆｎｏｄｅはまた、そ
れらのファイル又はディレクトリのネームの最初の部分
を収容している。従って、ＳＨＯＤＳは、Ｆｎｏｄｅ、
割当てセクタ及びディレクトリブロックに対してディス
クを規則正しく走査し、Ｆｎｏｄｅ、割当てセクタ及び
ディレクトリブロックを用いてファイル及びディレクト
リダイアグラムに空きスペースのビットマップを再創出
（ｒｅｇｅｎｅｒａｔｉｎｇ）することにより、全ボリ
ュームをリビルドすることができる。上記のように、本
発明は、ファイル及びディレクトリを理論的に順序付け
するのに、Ｂ＋ツリー及びＢ−ツリー（２進ツリー）を
用いている。２進ツリーは、データを物理的に順序付け
することなくして、ポインタを用いてデータ項目の集合
を論理的に順序付けする技術である。図１２を参照すれ
ば、簡単な２進ツリーにおける各ノードには、ツリーに
おるノードの論理的位置を決定するキー値を含む或るデ
ータと、並びにノードの左右のサブツリーを指すポイン
タとが設けられている。ツリーを開始するノードはルー
ト（根）として知られており、ツリーの枝の端部に位置
するノードは、ときどきリーフ（葉）と呼ばれている。
データの特定ピースを見出すには、２進ツリーがルート
を横切るようにする。各ノードにおいて、所望のキーが
ノードのキーと比較される。両キーが一致しない場合に
は、所望のキーがノードのキーより小さいか大きいかに
基づいて、ノードのサブツリーの１つのブランチ又は他
のブランチが選択される。このプロセスは、一致が見出
されるまで、又は図１２に示すように空のサブツリーに
出合うまで続けられる。このような簡単な２進ツリー
は、理解と実施が容易であるけれども、実用に際しての
欠点を有している。キーが非ランダムな態様でツリーに
首尾良く分散されなかった付加されなかったりすると、
ツリーが全く非対称的になり、ツリーの横断時間が広範
囲に変化してしまう。アクセス時間を均一にするため、
多くのプログラマは、図５に示すようなＢ−ツリーとし
て知られているバランス形ツリーを好む傾向にある。Ｂ
−ツリーについての重要な点は、データが全てのノード
に記憶され、１つ以上のデータ項目が１つのノードに記
憶され、かつ、ツリーの全てのブランチが同じ長さをも
っているということである。Ｂ−ツリーの最悪の場合の
挙動（ｂｅｈａｖｉｏｒ）は予測可能であり、簡単な２
次ツリーの挙動より遙かに良好であるが、Ｂ−ツリーの
メインテナンスはかなり複雑である。新しいデータ項目
ノ付加、キーバリューの変更、又はデータ項目の削除に
より、ノードのスプリッティング（分割）又はマージン
グ（併合）が生じ、これにより、ツリーには他の作業の
カスケードが強制される。図１３に示すように、Ｂ＋ツ
リーは、２つのノード形式（内部ノードは他のノードを
指すだけであり、外部ノードは実際のデータを有してい
る）をもつＢ−ツリーの特殊化されたフォームである。
Ｂ−ツリーよりもＢ＋ツリーの優れている点は、Ｂ＋ツ
リーの内部ノードが、Ｂ−ツリーの中間レベルノードよ
り非常に多くの決定バリューを保持でき、そのため、ツ
リーの外のファンが高速になりかつブランチの平均長さ
が短くなることである。これにより、必要データを見出
すにはＢ＋ツリーのヴランチがその端部に続かなければ
ならないという事実を補償でき、一方、Ｂ−ツリーにお
いては、データは中間ノードにおいて発見され、或い
は、ルート（根）においてさえも発見される。本発明
は、ＯＳ／２オペレーティングシステムを改善したもの
であり、多くのユーティリティとＯＳ／２の現行バージ
ョンにおいて利用できるサブルーチンを用いて実施する
ことができる。本発明は、主としてＯＳ／２オペレーテ
ィングシステムに使用することを意図しているが、本発
明の原理は、実際のあらゆるコンピュータのオペレーテ
ィングシステムに適用できるものである。ここで説明す
る新しいユーティリティ及びサブルーチンを除き、他の
全てのユーティリティ及びサブルーチンは現在利用され
ていて良く知られたものである。ＯＳ／２オペレーティ
ングシステムの詳細な説明については、前述のＯＳ／２
プログラマ用参考書を参照されたい。本発明の改善され
たＯＳ／２オペレーティングシステムのボリュームマネ
ージメント（ｖｏｌｕｍｅ ｍａｎａｇｅｍｅｎｔ）
は、ＯＳ／２の従来のバージョンにおいて行われている
ものと同じデューディ、すなわち、悪いボリュームがド
ライブにインサートされたときの検出、ボリュームが除
去されたときの検出、ボリュームパラメータブロック
（ＶＰＢ）を介してドライブ内に置かれた新しいメディ
アに関する新しい情報の創出、適当なデバイスドライバ
との通信、新しいインサートメディアにアクセスする必
要のあるデバイス情報をシステムに与えること、バッフ
ァ及びＣＤＳ機構とのインターフェース、及び特定ボリ
ュームへの変更をシステムに知らせること等に応答する
ことができる。ＯＳ／２の従来のバージョンにおいて
は、僅かに１つのファイルシステムがあったに過ぎな
い。本発明によれば、統一された環境内に多数のファイ
ルシステムを設けることができる。ボリュームマネージ
ャは、どのファイルシステムを特定のボリュームにアク
セスさせるべきかを決定し、ファイルシステムドライバ
（ＦＳＤｓ）が特定のボリュームについてのそれらの資
源（ｒｅｓｏｕｒｃｅｓ）を管理（マネージ）できるよ
うにする機構を提供し、かつボリュームの管理のために
過去に設けられた全てのＦＳＤｓに対して同じサポート
を提供する。本発明は、良く知られている既存のＯＳ／
２呼び出し（ＯＳ／２ ｃａｌｌｓ）並びに以下に説明
する幾つかの新しい機能を有している。本発明の設置可
能（ｉｎｓｔａｌｌａｂｌｅ）なファイルシステムにつ
いての完全な説明は、マイクロフィッシュの形態で本願
に添付されかつ参考として掲示する付録Ｉ（Ａｐｐｅｎ
ｄｉｘＩ）において述べられている。本発明は、個々の
ボリュームについての正しいファイルシステムドライバ
の識別及びローディングが容易に行えるマウンドプロセ
ス及びアンマウントプロセスを用いることを意図してい
る。マウントプロセスは、幾つかの異なる事象が生じた
とき、すなわち、 １． ボリュームへの最初のアクセスがあったとき、 ２． ドライブのボリュームが不確実になる（このこと
は、通常、ユーザが新しいメディアをドライブに入れる
ことを意味する）全てのとき、 ３． ドライブ内にないボリュームへのアクセスが要求
される全てのとき、に開始される。 マウントプロセスへの入力は、ドライブパラメータブロ
ック（ＤＰＢ）（このドライブパラメータブロックは、
デバイスドライバにＩ／Ｏを行うこと、及びドライブ内
にあると現在考えられているボリュームのＶＰＢにハン
ドルを記憶させることに使用される）を指すポインタで
ある。マウント作業によりこれが更新される。ローカル
ＶＰＢがスタック上に割り当てられ、ＤＰＢポインタと
共に初期化される。図１５に示すように、項目６０２で
示すようにメディアの論理的セクタ０を読み取ることに
より、マウントプロセス６００が開始される。デバイス
ドライバからの全てのエラーは無視する。なぜならば、
異なる形式のメディア（すなわち、光学ディスク又はＣ
Ｄ−ＲＯＭ）がトラック０を読取り不能にできるからで
ある。論理的セクタ０を読み取る前に、テンポラリマウ
ントバッファが０に初期化される。ボリュームのラベル
テキストフィールドが「ＵＮＬＡＢＥＬＥＤ」に初期化
される。セクタ０がチェックされ、特定バリュー（４
１）に対してサインバイト（ｓｉｇｎａｔｕｒｅｂｙｔ
ｅ）を比較することにより、フォーマットが認識されて
いるか否かを決定する。フォーマットが認識されていな
い場合には、ＶＰＢに近い情報がスタック上に充填され
る（すなわち、３２ビットボリューム連続番号（３２
Ｂｉｔ Ｖｏｌｕｍｅ Ｓｅｒｉａｌ Ｎｕｍｂｅ
ｒ））。次に、項目６０４により、ＢＵＩＬＤＢＰＢ呼
び出し（ＢＵＩＬＤＢＰＢ ｃａｌｌ）が、ＤＰＢにお
いて特定化されたデバイスドライバに発行される。ＢＵ
ＩＬＤＢＰＢは、デバイスドライバによりエクスポート
（移出）される手順である。このＢＵＩＬＤＢＰＢ手順
については、付録Ｉにおいて詳細に説明されている。Ｂ
ＵＩＬＤＢＰＢは、装置の物理パラメータ（バイトパー
セクタ（ｂｙｔｅｐｅｒ ｓｅｃｔｏｒ）、セクタパー
トラック（ｓｅｃｔｏｒ ｐｅｒ ｔｒａｒｃｋ）等）
を学習させるべく呼び出される。デバイスドライバは、
ボリュームの物理パラメータを決定するのに用いること
ができる情報を収容しているパッファを指すポインタに
導かれる。殆どのドライバにとっては、これはセクタ０
であり、非常に古い幾つかのドライバにとっては、ＦＡ
Ｔの最初のセクタである。装置が、セクタ０から読み取
られるデータを解釈できない場合（例えば、この場合の
フロッピがＦＡＴではなく、従ってＦＡＴ ＩＤバイト
が意味をもたない場合）には、装置は最小のＢＰＢを戻
し、カーネル及びＦＳＤｓが必要なＩ／Ｏを行って、ボ
リュームを完全に識別できるようにする。前に創出され
たＢＰＢからの適合フィールド（ｒｅｌｅｖａｎｔ ｆ
ｉｅｌｄ）は、スタックのローカルＶＰＢ（すなわち、
Ｓｅｃｔｏｒｓ／ｔｒａｃｋ、Ｎｕｍｂｅｒ ｏｆ Ｈ
ｅａｄｓ、Ｔｏｔａｌ Ｓｅｃｔｏｒｓ、Ｓｅｃｔｏｒ
Ｓｉｚｅ）にコピーされる。新しいＶＰＢが割り当てら
れ、ローカルＶＰＢからの情報がそれにコピーされる。
次に、本発明によれば、ループ６０６に入り、項目６０
８で示すように、新しい創出されたＶＰＢ、論理的セク
タ０を指すポインタ、及びＶＰＢファイルシステムの独
立及び従属領域（ｉｎｄｅｐｅｎｄｅｎｔａｎｄ ｄｅ
ｐｅｎｄｅｎｔａｒｅａｓ）を指すポインタを備えたＦ
Ｓ ＭＯＵＮＴ（フラグ＝０）の入口点を呼び出すこと
により、各ＦＳＤをボール（ｐｏｌｌ）する。ＦＳＤは
ＦＳＨ ＤｏｖｏｌＩＯを呼び出し、ボリュームから他
のセクタを読み取る（それ自体のバッファを割り当てな
くてはならない）。ＦＳＤが、ＥＲＲＯＲ ＵＮＣＥＲ
ＴＡＩＮ ＭＥＤＩＡに戻る場合には、エラーが戻さ
れ、プロセスは、決定（ｄｅｃｉｓｉｏｎ）６１０によ
り示すように再スタートされる。ＦＳＤがブートセクタ
をサポートする場合には、ＦＳＤは、ブートセクタのフ
ァイルシステムのネームフィールドをチェックして、こ
れがネームフィールドを認識しているか否かを決定す
る。ＦＳＤがブートセクタをサポートしない場合には、
ＦＳＤがボリュームを認識しているか否かを決定すべ
く、装置へのＩ／Ｏが行われる。ＦＳＤがひとたびボリ
ュームを認識しているならば、項目６１２で示すよう
に、ＶＰＢファイルシステムの独立及び従属領域におけ
る適合フィールドを更新する。ＶＰＢファイルシステム
の独立及び従属領域については、図１６に関連して更に
詳細に説明する。この時点においては、ＦＳＤはＦＳ
Ｈｅｐｏｅｒ（ＦＳＨ）機能を発行して、新しいボリュ
ームが、本発明が管理する他の任意のボリュームと同じ
であるか否かを決定する。このＦＳ Ｈｅｌｐｅｒは、
ファイルシステムの独立及び従属領域にポインタを戻
す。次いでＦＳＤは、項目６１４で示すように、新しく
創出されたＶＰＢから古いＶＰＢへと情報をコピーす
る。新しい創出されたＶＰＢは、ＭＯＵＮＴの呼び出し
を行った後に破壊される。次に、ＦＳＤは、あらゆるバ
ッファを無効にするような古いＶＰＢに対してあらゆる
クリナップ作業（ｃｌｅａｎｕｐ ｗｏｒｋ）を行う。
これは、ドライブからボリュームが除去されていること
からである。本発明によれば、ひとたびＦＳＤがボリュ
ームを認識すると、リスト内に一致するものが見出され
る場合には新しいＶＰＢが除去される。リスト内に一致
するものが見出されない場合には、ＶＰＢは、マウント
されたＦＳＤｓのリストにリンクされる。ＦＳＤｓが認
識されない場合には、決定６１４及び項目６１６に示す
ように、ＶＰＢが空にされかつＦＡＴファイルシステム
がマウントされる。新しいボリュームがドライブにイン
サートされかつ古いボリュームに対してカーネルがもは
や関与しない場合には、本発明では、ＦＳＤにＦＳ Ｍ
ＯＵＮＴ（フラグ＝２）が発行され、これにより、この
ボリュームに割り当てられた資源の割当てを解除するよ
うになっている。本発明により、新しくインサートされ
たボリュームが、ドライブの最終ボリュームとは異なる
ものであることが検出された場合には、ＦＳＤに対しＦ
Ｓ ＭＯＵＮＴ（フラグ＝１）の呼出しが発行され、こ
れにより、除去されたボリュームに関するバッファ無効
のようなあらゆるクリナップ形式の作業を行うことがで
きる。ボリュームに対してもはやカーネルが関与しない
場合には、ＦＳ ＭＯ ＮＴ（フラグ＝２、ＵＮＭＯＵ
ＮＴ）が続いて行われる。新しくインサートされたボリ
ュームが、ドライブにおいて最終的に見出されたボリュ
ームと同じものである場合には、この呼出しは発行され
ない。本発明は、ＦＳＤにより要求される機能に対する
既存のカーネル資源を利用するのに、効率の良い機構を
用いることを意図するものである。より詳しくは、ＦＳ
Ｄがカーネル内に存在する機能を要求する場合には、Ｆ
ＳＤは、ファイルシステムヘルパ（ＦＳＨ）を呼び出す
（ｉｎｖｏｋｅ）ファイルシステムヘルパ呼出し（ｃａ
ｌｌ）を発行する。呼び出されたＦＳＨは、次に、要求
された情報を戻す。以下に、ファイルシステムヘルパに
ついて簡単に説明する。以下に述べる要約においては幾
つかの重要なファイルシステムヘルパがリストアップさ
れているけれども、必要に応じて付加的なファイルシス
テムヘルパを設けることができる。ファイルシステムヘ
ルパは、Ａｐｐｅｎｄｉｘ Ｉにおいて詳細に説明され
ている。ファイルシステムヘルパ（Ｆｉｌｅ Ｓｙｓｔｅｍ Ｈ
ｅｌｐｅｒｓ） ＦＳＨ ＧＥＴＶＯＬＰＡＲＭ：多くのＦＳ呼出し時
に、ＶＰＢへのハンドルがＦＳＤに導かれ、ＦＳＤが、
ＶＰＢのファイルシステムの独立及び従属領域にアクセ
スすることがしばしば必要になる。このヘルパは、その
ようなサービスを与えるものである。 ＦＳＨ ＤＯＶＯＬＩＯ：ＦＳＤが、特定のボリューム
に対してＩ／Ｏを行う必要があるときには、ＦＳＤは、
このヘルパを使用して、要求されたボリュームが実際に
ドライブ内にあることを保証し、適当なデバイスドライ
バを呼び出し、かつハードエラーを取り扱う。このヘル
パは、ＦＳＤ内で常時用いることができる。ＦＳ＿ＭＯ
ＵＮＴ呼出しの範囲内で呼び出されるとき、ＦＳＤはド
ライブのボリュームに適用される。しかしながら、ＦＳ
ＤがＦＳ＿ＭＯＵＮＴ呼出しに戻るまでは、ボリューム
の認識が完了していないので、ＥＲＲＯＲ ＵＮＣＥＲ
ＴＡＩＮ ＭＥＤＩＡが戻される場合には、ＦＳＤに注
意しなければならない。このことは、ドライブにおける
メディアの識別を試みる間に、メディアが不確実になっ
ていることを示すものである。また、このことにより、
ＦＳＤが認識を試みていたボリュームが除去されたこと
を示すようにすることもできる。この場合には、ＦＳＤ
は、ＦＳ＿ＭＯＵＮＴ呼出しに導かれたｈＶＰＢに取り
付けられた（ａｔｔａｃｈｅｄ）全ての資源を解放し、
ＥＲＲＯＲ ＵＮＣＥＲＴＡＩＮ ＭＥＤＩＡがＦＳ＿
ＭＯＵＮＴ呼出しに戻される。これにより、ボリューム
トラッキング論理が、マウントプロセスを再スタートす
るように命令される。ＦＳＨＤＵＰＬＩＣＡＴＥＶＰ
Ｂ：ＦＳ＿ＭＯＵＮＴ呼出しの間、入力ＶＰＢは、管理
されている他の１つのボリュームと同じボリュームにす
ることができる。新しいボリュームに関する更新情報を
創出しかつ古い複製ＶＰＢ（ｏｌｄｅｒ ｄｕｐｌｉｃ
ａｔｅ ＶＰＢ）への情報をコピーすることは、ＦＳＤ
の責任である。このヘルパは、古い複製ＶＰＢが存在し
ているか否かを決定し、存在している場合には、古い複
製ＶＰＢのファイルシステムの独立及び従属領域を指す
ポインタを戻し、これらの領域がＦＳＤによって更新さ
れるようにする。次いで、ＦＳＤは、ボリュームが除去
されているので、古いボリュームについてあらゆるクリ
ナップ作業を行う。上記のように、本発明は、可能な限
り、予め存在しているＯＳ／２資源を使用することを狙
ったものである。以下のリストは、本発明の作業中に呼
び出される機能の階層（ｈｉｅｒａｒｃｈｙ）を要約し
たものである。 本発明によれば、メディアが不確実であるか否か又はメ
ディアが最初にアクセスされたか否かが呼び出される。
本発明のボリュームマネージメント機能（ボリューム管
理機能）はライン１．により表される。最初のプロセス
は、ライン１．１で示すように、どのボリュームがシス
テムに表されたかを決定することである。ライン１．
１．１のＰｒｏｂｅ Ｃｈａｎｇｅは、デバイスドライ
バにアクセスすべく呼び出され、メディアの変化をデバ
イスドライバが検出したか否かを決定する。メディアの
変化が検出されたときは、ライン１．１．２においてＲ
ｅｓｅｔＭｅｄｉａが呼び出され、デバイスドライバが
メディアにＩ／Ｏできることを知らせる。次に、ライン
１．１．３においてＧｅｎｈＶＰＢが呼び出され、ボリ
ュームパラメータブロックが創出される。このプロセス
は、ＬｏｃｋＶＢｕｆが呼び出されてオペレーティング
システムのカーネル内のバッファをクリアしかつ直列化
（ａｅｒｉａｌｉｚｅ）するライン１．１．３．１と共
に開始する。ライン１．１．３．２においては、メディ
アブートセクタのデータが、オペレーティングシステム
のバッファに読み取られる。システムはライン１．１．
３．３に続き、該ライン１．１．３．３においては、Ｂ
ｕｉｌｄＢＰＢが呼び出されて（ｉｎｖｏｋｅｄ）、デ
ィスクドライバを呼び出し（ｃａｌｌ）、ブートパラメ
ータブロックを作る。次に、．ＦＳ＿ＭＯＵＮＴがライ
ン１．１．３．４に呼び出される。ＦＳ＿ＭＯＵＮＴに
おける最初のステップは、ライン１．１．３．４．１の
Ｂｍｐ Ｇｅｔを呼び出す。ライン１．１．３．４．１
は、ＢＰＢのバッファを設定すべく呼び出されカーネル
におけるメモリマネージメントユーティリティである。
ライン１．１．３．４においては、ＦＳＭｏｕｎｔＶｏ
ｌｕｍｅが呼び出されると、ＦＳＭｏｕｎｔＶｏｌｕｍ
ｅは、ＦＳＤｓのリストを介して反復し、サクセスに戻
るかリストの終部（エンド）に到達するまで、各ＦＳＤ
のＦＳ＿Ｍｏｕｎｔ手順を呼び出す。ライン１．１．
３．４．２においてＦＳＤがサクセスに戻ると、ＶＰＢ
Ｃｏｐｙが呼び出されて、ＢＰＢのコピーに対するテン
ポラリバッファを創出する。次に、ライン１．１．３．
４．３におけるＶＰＢＬｉｎｋが呼び出され、ＶＰＢを
チェーンにリンクさせ、該チェーンにおける次のＶＰＢ
を指すべくＢＰＢを設定し、現在のＶＰＢをリストの開
始に初期化する。ＶＰＢＦｉｎｄがライン１．１．３．
４．４に呼び出されてＶＰＢｓのチェーンを試験し、プ
ロセス中のＶＰＢと同じボリューム識別子を所有してい
るＶＰＢを見出す。複製ＶＰＢの識別子が。見出された
場合には、ライン１．１．３．４．５にＶＰＢｆｒｅｅ
が呼び出され、複製ＶＰＢがＶＰＢｓのリスト内に見出
された場合には、試験を受けてＶＰＢがＶＰＢから自由
になる。ＦＳＭｏｕｎｔＶｏｌｕｍｅが完了すると、Ｖ
ＰＢに適当なフィールドを設定するライン１．１．３．
５．にＳｅｔＶＰＢが呼び出される。ライン１．１．
３．６において、ＦｉｎｄＶＩＤが呼び出され、ボリュ
ーム識別子が見出される。メディアのセクタ０にブート
ブロックが見出されない場合には、ライン１．１．３．
７にＤｉｓｋＩＯが呼び出され、ボリュームのＢＰＢが
位置付けされる。ＦＳＤのＦＳ＿ＭＯｕｎｔルーチンが
サクセスに戻らない場合には、（残留）ＦＡＴファイル
システムのＦＳ＿Ｍｏｕｎｔ手順と論理的に等価のイン
ラインコードが呼び出される。ライン１．１．３．８に
おいては、ＣＲＣが呼び出されて、古いＦＡＴボリュー
ムの最初のディレクトリが検査合計（ｃｈｅｃｋｓｕ
ｍ）され、それらのブートセクタの連続番号をもたない
ボリュームについてのユニークなボリューム連続番号が
創出される。次に、ライン１．１．３．９〜ライン１．
１．３．１３にリストアップされた機能が呼び出され
て、新しいボリューム識別子が創出されかつボリューム
識別子バッファが空にされる。ライン１．１．２．１４
においてはＢｕｆｌｎｖａｌｉｄａｔｅが呼び出され
て、プロセス開始以来メディアが変化している場合には
バッファ内の全てのデータが無効にされる。その場合に
は、ライン１．１．３．１５にＦｌｕｓｈＢｕｆが呼び
出され、新しいメディアに対してバッファをフラッシュ
させる。 ボリュームについて前から存在しているＶＰ
Ｂが見出されない場合には、ライン１．１．４のＩｎｃ
ＶＰＢＲｅｆが呼び出されて、現在のＶＰＢの基準カウ
ンタが増大（ｉｎｃｒｅｍｅｎｔ）される。この基準カ
ウンタは、ここで問題にしているボリュームが、オペレ
ーティングシステムのカーネルに対して依然として開放
しているか否かを記録するのに使用される。ライン１．
１．５においては、ＤｅｃＶＰＢＲｅｆが呼び出され、
前のＶＰＢの基準カウンタが減少（ｄｅｃｒｅｍｅｎ
ｔ）される。基準カウンタがゼロに減少された場合は、
ＶＢＰＦｒｅｅがライン１．１．５．１に呼び出され、
ＶＰＢが空にされる。ライン１．１．６にはＲｅｓｅｔ
Ｃｕｒｒｅｎｃｙが呼び出され、現在のディレクトリ構
成における位置データが無効であるとしてマークする。
ＮｅｘｔＣＤＳ（ライン１．１．６．１）及びＰｏｉｎ
ｔＣｏｍｐ（ライン１．１．６．２）は、現在のディレ
クトリ構成（ＣＤＳｓ）を列挙するのに用いられる内部
ルーチンである。ライン１．１．６．３においてＢｕｆ
Ｉｎｖａｌｉｄａｔｅが呼び出され、ファイルシステム
のバッファプールから、（現在は陳腐化している）ＶＰ
Ｂ基準が除去される。上記のように、ＶＰＢは、コンピ
ュータシステムに使用されている特定のボリュームにつ
いての情報を記憶するシステムにより用いられる。ボリ
ュームは、ブロック装置におけるメディアとして構成さ
れ、メディアに関する情報は、このボリュームを他の全
てのボリュームから区別する。ＶＰＢｓは、ＢＭＰとし
てセグメントに維持される。従って、システムは記録が
使用されているトラックのみを必要とし、かつ空のリス
トが管理される。新しいボリュームに出合う度毎に、す
なわち、ボリュームのＶＰＢ作製（ＶＰＢ ｂｕｉｌ
ｔ）がシステムに既存のいかなるＶＰＢｓとも一致しな
い度毎に、新しい入口（ｎｅｗｅｎｔｒｙ）が、ＢＭＰ
管理されたセグメント内で割当てられ、メディアからの
等価データで充填される。システムがＶＰＢが完了する
度毎に、すなわち、システムのＲｅｆＣｏｕｎｔがゼロ
になる度毎に、ＢＭＰ管理されたセグメントの入口が空
になり、ＢＭＰは、この空になった記憶機構（ｓｔｏｒ
ａｇｅ）を再使用のためにトラックする。テーブルＩの
機能により用いられた構成を以下に説明する。ＶＰＢ
は、次の３つの部分に分割される。 １． カーネルのプライベート部分。この部分は、情報
をカーネルに維持するのに使用され、ＶＰＢ（例えば、
基準カウント）の管理を必要とする。これは、カーネル
にとってのプライベートなものであり、ＦＳＤｓは決し
てこのプライベート部分にアクセスしないしかつこれを
変更することがないことを意味している。 ２． ファイルシステムの独立部分。この部分は、全て
のファイルシステムにより使用されかつ特定のあらゆる
ファイルシステムから独立している。この部分は、或る
ファイルシステム（ｆｉｌｅ ｓｙｓｔｅｍ、「Ｆ
Ｓ」）の要求に応じて、設置可能なファイルシステムに
導かれる。 ３． ＶＰＢを用いているファイルシステムに特有の部
分。この部分は、必要に応じてファイルシステムを使用
できる「作業領域」として設定される。この部分は、或
るＦＳの要求に応じてＩＦＳに導かれる。ＶＰＢのレイ
アウトは図１６に示されている。次の構成は、ファイル
システムのＶＰＢとは独立した部分を明らかにするもの
である。この構成は、ファイルシステムの形式の如何に
係わりなく、あらゆるファイルシステムにより使用でき
るものである。 下記の構成は、ＶＰＢのファイルシステムの従属部分を
定めるものである。この構成は、適合すると考えられる
ファイルシステムにより使用される。 下記の構成は、ボリュームパラメータブロック（ＶＰ
Ｂ）の構成を定めるものである。 下記の構成は、ＦＳＨ ＧＥＴＶＯＬＰＡＲＭ（これ
は、ＶＰＢハンドルからＶＰＢデータを得るのに使用さ
れる）により使用される。 下記の構成は、ＦＳＨ ＤＯＶＯＬＩＯ（これは、ボリ
ュームベース形セクタ配向転送（ｖｏｌｕｍｅ−ｂａｓ
ｅｄ ｓｅ−ｃｔｏｒ−ｏｒｉｅｎｔｅｄ ｔｒａｎｓ
ｆｅｒｓ）に使用される）により使用される。 下記の構成は、ＦＳＨ ＤＵＰＬＩＣＡＴＥＶＰＢ（こ
れは、複製（古い）ＶＰＢへのＶＰＢデータを得るのに
使用される）により使用される。 ＲｅｄｅｔｅｒｍｉｎｅＭｅｄｉａは、下記に示すよう
な特殊な組の入口パラメータ（ｅｎｔｒｙ ｐａｒａｍ
ｅｔｅｒｓ）を有している。 下記の呼び出しは、ボリューム管理の内部コンポーネン
トインターフェースに使用される。ＧｅｎｈＶＰＢは、
特定のドライブの内部ＶＰＢの決定に使用される。戻さ
れた全てのエラーは、ユーザに送られる。 全てのレジスタは、変更することができる。Ｂｕｉｌｄ
ｄＢＰＢは、古いディスク（すなわち、認識されたプー
トセクタを有していないディスク）用の正しいＢＰＢを
創出すべく呼び出される。新しいディスクは、ブートセ
クタ内に、ＫＮＯＷＮ（既知）で正しいすなわち正当な
ＢＰＢ（ＶＡＬＩＤ ＢＰＢ）を有している。デバイス
ドライバへのバッファは、ＢｕｉｌｄＢＰＢ呼び出しの
一部である。 全てのレジスタは、ＢＰを除く全てを変更した。ＦＳＭ
ｏｕｎｔＶｏｌｕｍｅは、ＩＦＳドライブが、関心をも
つボリュームを認識しているか否かを決定すべくチェッ
クする。ＦＳＭｏｕｎｔＶｏｌｕｍｅは、各ＦＳドライ
バのＦＳ＿Ｍｏｕｎｔ入口点を呼び出すＦＳＤチェーン
を通してループし、ＩＦＳが、関心をもつボリュームを
認識しているか否かを決定する。このループは、最初の
ＩＦＳがボリュームを認識するとき、又はシステム内に
設置されたＦＳドライバの番号のループカウンタが０に
減少するときに、終端する。 変更されたレジスタ；ａｘ，ｂｐ，ｂｘ，ｄｉ，ｅｓ，
ｓｉ，ＶＰＢＦｒｅｅは、リンクリストからＶＰＢを除
去して、セグメントからそのブロックを空にする。 ＶＰＢＬｉｎｋは、リストの開始時に新しいＶＰＢをイ
ンサートし、新しいＶＰＢ及び古い最初のＶＰＢの前方
及び後方のリンクフィールドを調節する。 ＶＰＢＦｉｎｄは、内部リストを走査して、入力ＶＰＢ
と同じボリュームＩＤをもつＶＰＢを探す。 ＶＰＢＣｏｐｙは、ローカル領域からＢＭＰ管理領域に
ＶＰＢをコピーし、かつ正当であるとしてＶＰＢをスタ
ンプする。 悪いボリュームがマウントされたときにこれを検出して
オペレータに正しい処置をとるように知られること、す
なわちボリュームマネージメント（ボリューム管理）
は、オペレーティングシステムのカーネル及び適当なデ
パイスドライバを介して直接行われる。本発明の原理に
よれば、各ファイルシステムドライバ（ＦＳＤ）は、ボ
リュームラベルと、ファイルシステムに使用される各ボ
リュームについての３２ビットのボリューム連続番号と
を創出するようになっている。これらは、ボリュームが
フォーマット化されるときに、理論的セクタゼロのリザ
ーブされた位置に記憶させるのが好ましい。この情報を
記憶するのに、特別のフォーマットが必要になることは
ない。オペレーティングシステムのカーネルは、ＦＳＤ
を呼び出して、これを含むことがある作業を実行する。
ＦＳＤは、ボリュームラベル又は連続番号が変更された
場合には、いつでもボリュームパラメータブロック（Ｖ
ＰＢ）を更新する。ＦＳＤがＩ／ＯリクエストをＦＳヘ
ルパルーチンに導くと、デバイスドライバは、３２ビッ
トのボリューム連続番号及びボリュームラベルを（ＶＰ
Ｂを介して）導く。ボリュームに関してＩ／Ｏが実行さ
れるとき、オペレーティングシステムのカーネルは、リ
クエストされたボリュームの連続番号を、装置を維持し
ている現在のボリュームの連続番号と比較する。これ
は、ドライブにマウントされたボリュームのドライブパ
ラメータブロック（ＤＰＢ）のＶＰＢをチェックするこ
とにより行われるインストレージ試験（ｉｎ−ｓｔｏｒ
ａｇｅ ｔｅｓｔ）であり、いかなるＩ／Ｏも必要とさ
れない。比較の結果、等しくない場合には、オペレーテ
ィングシステムのカーネルは、クリチカルエラーハンド
ラに信号を発生して、特定の連続番号及びラベルをもつ
ボリュームをユーザがインサートすることを促進させ
る。メディアの変化が検出されると、アプリケーション
プログラムのインターフェース（ＡＰＩ）の機能呼び出
しの代わりに、ドライブがアクセスし、本発明によれ
ば、そのボリュームに対するマネージングＩ／Ｏに応答
できるファイルシステムドライバ（ＦＳＤ）が決定され
る。次に、本発明は、ボリュームパラメータブロック
（ＶＰＢ）を割当て、設置されたＦＳＤｓをボーリング
（ｐｏｌｌ）する。ＦＳＤは、これがメディアを認識し
ていることを表示する。ＦＳＤｓは上記のようにしてボ
ーリングされる。ＦＡＴのＦＳＤは、ＦＳＤｓのリスト
の最後にあり、他のＦＳＤの認識が生じない場合には、
全てのメディアを認識することにより、省略時ＦＳＤ
（ｄｅｆａｕｌｔＦＳＤ）として作用する。本発明の原
理によれば、ファイルシステムドライバには、次の２つ
のクラス、すなわち、 １． ローカルすなわち遠隔（仮想ディスク）装置に対
してＩ／Ｏを行うブロックデバイスドライバを用いてい
るＦＳＤ（これは、ローカルファイルシステムと呼ばれ
ている）と、 ２．ブロックデバイスドライバを用いることなくして遠
隔システムにアクセするＦＳＤ（これは、遠隔ファイル
システムと呼ばれている）とがある。ドライブレター
（ドライブ文字）と遠隔ファイルシステムとの間の連結
はプログラムされたインターフェースを介して行われ
る。システムのネームスペース（例えば、ドライブ）の
目的とＦＳＤとの間の結合を生じさせるには、ＤｏｓＦ
ＳＡｔｔａｃｈシステムの呼出しが用いられる。疑似文
字装置（ｐｓｅｕｄｏ−ｃｈａｒａｃｔｅｒ ｄｅｖｉ
ｃｅ）と遠隔ファイルシステムとの間の連結も、Ｄｏｓ
ＦｓＡｔｔａｃｈインターフェースを介して行われる。
ＤｏｓＦｓＡｔｔａｃｈインターフェースは、ＤｏｓＦ
ｓＡｔｔａｃｈ呼出し及びＤｏｓＱＦｓＡｔｔａｃｈ呼
出しで構成されており、これらは、Ａｐｐｅｎｄｉｘ
Ｉにおいて詳細に説明されている。ローカルボリューム
が最初に参照されるとき、本発明では、ＦＳＤチェーン
の各ローカルＦＳＤを連続的に尋ねて（ａｓｋ）、各Ｆ
ＳＤのＦＳ＿ＭＯＵＮＴ入口点への呼出しを介してメデ
ィアを受け入れるようになっている。どのＦＳＤもメデ
ィアを受け入れない場合には、メディアは、省略時ファ
イルシステムに割り当てられる。ＦＯＲＭＡＴでは認識
されないメディアにアクセスするため行われる他の全て
の試みがなされて、「無効（正しくない）メディアフォ
ーマット（ＩＮＶＡＬＩＤ ＭＥＤＩＡ ＦＯＲＭＡ
Ｔ）」のエラーメッセージが出される。ひとたびボリュ
ームが認識されると、ドライブと、ＦＳＤと、ボリュー
ムの連続番号と、ボリュームのラベルとの間の関係が記
憶される。ボリュームの連続番号及びラベルは、ボリュ
ームのパラメータブロック（ＶＰＢ）に記憶される。Ｖ
ＰＢは、開放ファイル（Ｉ／Ｏに基づくファイルハンド
ル）、サーチ及びバッファリファレンス（ｂｕｆｆｅｒ
ｒｅｆｅｒｅｎｃｅｓ）についてのオペレーティング
システムにより維持される。除去されたボリュームに対
する連続リクエストは、ＦＳ＿ＭＯＵＮＴを呼び出すこ
とによりボリュームについての設置されたＦＳＤｓのボ
ーリングを要する。認識しているＦＳＤにより戻された
ＶＰＢ及び既存のＶＰＢのボリューム連続番号及びボリ
ュームラベルが比較される。試験が成功した場合には、
ボリュームにＦＳＤがアクセスされる。これに対し、試
験が失敗した場合には、オペレーティングシステムがク
リチカルエラーハンドラに信号を伝達し、ユーザがボリ
ュームを矯正することを促進させる。メディアとＶＰＢ
との間の連結は、ボリュームの全ての開放ファイルが閉
じられるまでセーブされ、サーチリファレンス及びキャ
ッチシュバッファリファレンスが除去される。ボリュー
ムの変化によってのみ、次のアクセス時にメディアの再
決定がなされる。ブート可能で論理的に区分（ｐａｒｔ
ｉｔｉｏｎ）されたメディアに関するオペレーティング
システムの区分へのアクセスは、ＯＳ／２オペレーティ
ングシステムに利用できる機能セット（機能組）のよう
なフルオペレーティングシステムの機能セットを介して
行われる。ディスクの区分化の設計（ｄｉｓｋ ｐａｒ
ｔｉｔｉｏｎｉｎｇ ｄｅｓｉｇｎ）についての詳細な
説明が、前述のＯＳ／２プログラマ用参考書においてな
されている。本発明によれば、ネットワークを介してオ
ペレーティングシステムと通信する遠隔装置を識別する
ためのＤｏｓＱＦｓＡｔｔａｃｈ機能が提供される。Ｄ
ｏｓＱＦｓＡｔｔａｃｈの目的は、取り付け（ａｔｔａ
ｃｈ）られた遠隔ファイルシステム、ローカルファイル
システム、文字装置（ｃｈａｒａｃｔｅｒ ｄｅｖｉｃ
ｅ）、又は、ローカルＦＳＤ又は遠隔ＦＳＤに取り付け
られた疑似装置ネームに関する情報を尋ねることであ
る。ＤｏｓＱＦｓＡｔｔａｃｈを呼び出すシーケンスは
次の通りである。 ここで、ＤｅｖｉｃｅＮａｍｅは、コロン（：）を付し
た駆動文字（ｄｒｉｖｅ ｌｅｔｔｅｒ）を指すか、或
は文字又は疑似文字装置ネームを指し、ＦＳＡＩｎｆｏ
ＬｅＶｅｌの幾つかのバリューは無視する。Ｄｅｖｉｃ
ｅＮａｍｅが文字又は疑似文字であるときには、Ｄｅｖ
ｉｃｅＮａｍｅは、コロンを付した疑似文字の形態を有
するＡＳＣＩＺストリングである。ＤｅｖｉｃｅＮａｍ
ｅが、文字又は疑似文字の装置ネームであるときには、
そのフォーマットは、サブダイレクトリ呼出しのファイ
ルネームのフォーマットにおけるＡＳＣＩＩＺストリン
グのフォーマットであり＼ＤＥＶ＼のように示すのが好
ましい。序数（ｏｒｄｉｎａｌ）は、文字装置、疑似文
字装置又はドライブの組のリストのインデックスであ
る。序数は常に１からスタートする。リストの１つの項
目の序数位置は重要でない。序数は、リスト全体を厳格
にステップするのに使用される。序数から項目へのマッ
ピングは揮発性であり、ＤｏｓＱＦＡｔｔａｃｈに対す
る或る呼出しから次の呼出しまで変化することができ
る。ＦＳＡＩｎｆｏＬｅｖｅｌは、要求される情報のレ
ベルであり、ＤａｔａＢｕｆｆｅｒのデータがどの項目
に関するものであるかを決定する。レベル０×０００１
は、ＤｅｖｉｃｅＮａｍｅにより名付けられた特定のド
ライブ又は装置ネームのデータを戻す。序数のフィール
ド（欄）は無視する。レベル０×０００２は、序数によ
り選択された文字又は疑似文字装置のリストの入口のデ
ータを戻す。ＤｅｖｉｃｅＮａｍｅのフィールドは無視
する。レベル０×０００３は、序数によって選択された
ドライブのリストの入口のデータを戻す。Ｄｅｖｉｃｅ
Ｎａｍｅのフィールドは無視する。ＤａｔａＢｕｆｆｅ
ｒは戻り情報バッファ（ｒｅｔｕｒｎ ｉｎｆｏｒｍａ
ｔｉｏｎ ｂｕｆｆｅｒ）であり、次のフォーマット内
にある。 ｓｚＦＳＮａｍｅは、ＦＳＤにより移出（エクスポー
ト）されたＦＳＤネームであり、このネームは、必ずし
もブートセクタのＦＳＤネームと同じネームである必要
はない。ローカル文字装置（ｉＴｙｐｅ＝１）について
は、ｃｂＦＳＤＮａｍｅ＝０であり、ｓｚＦＳＤＮａｍ
ｅは、ゼロで終わるバイトのみを含んでいて、ｃｂＦＳ
ＡＤａｔａ＝０である。ローカルドライブ（ｉＴｙｐｅ
＝３）については、ｓｚＦＳＤＮａｍｅは、呼出しの時
点でドライブに取り付けられたＦＳＤのネームを含んで
いる。この情報はダイナミックに変化する。ドライブが
オペレーティングシステムのカーネルの常駐ファイルシ
ステムに取り付けられている場合には、ｓｚＦＳＤＮａ
ｍｅに“ＦＡＴ”又は“ＵＮＫＮＯＷＮ”が含まれるで
あろう。常駐ファイルは、マウントを拒むＦＳＤｓ以外
の任意のディスクに取り付けられるので、認識可能なフ
ァイルシステムを含んでいないディスクを設けることが
できるが、常駐ファイルシステムに取り付けることもで
きる。この場合、差異を検出することができ、この情報
は、破壊されないデータのプログラムが、適正に認識さ
れなかったディスクに存在することを助ける。Ｄａｔａ
ＢｕｆｆｅｒＬｅｎは、戻りバッファのバイト長さであ
る。戻り時においては、この長さは、ＦＳＤによりＤａ
ｔａＢｕｆｆｅｒに戻されたデータの長さである。 全てのブロック装置及び全ての文字及び疑似文字装置に
ついての情報は、ＤｏｓＱＦｓＡｔｔａｃｈにより戻さ
れる。この呼出しにより戻される情報は、揮発性が強
い。戻された情報は、これらが戻されるときまでに既に
変化されていることを呼出しプログラムが気付くことが
できるようにするのが好ましい。カーネルの常駐ファイ
ルシステムに取り付けられたディスクに戻された情報
は、ディスクがファイルシステムを備えたものであるこ
とをカーネルが明確に認識しているか否かの決定、又は
カーネルがそのファイルシステムをカーネルに取り付け
たか否か（他のＦＳＤｓはディスクを取り付けていない
からである）の決定を行うのに使用することができる。
全てのＦＳＤｓへのエラー信号についてのエラーコード
の組は、０×ＥＥＯＯ−０×ＥＥＦＦである。必要に応
じて他のエラーを付加できるけれども、次のエラーが定
められている。ＥＲＲＯＲ ＶＯＬＵＭＥ＿ＮＯＴ Ｍ
ＯＵＮＴＥＤ＝０×ＥＥＯＯ−ＦＳＤは、ボリュームを
認識しなかった。各ＦＳＤにより定められるエラーコー
ドの組は、０×ＥＦＯＯ−０×ＦＥＦＦである。ディス
クメディア及びファイルシステムのレイアウトは、次の
構成により説明される。ファイルシステムに与えられる
データは、ブロック装置に取り付けられたデバイスドラ
イバにより与えられるファイルシステムサポートのレベ
ルに基づいている。これらの構成は、ローカルファイル
システムに対してのみ等価性を有している。 上記のように、ＦＳ ＭＯＵＮＴ機能は、ボリュームを
マウントしかつアンマウントすべく呼び出され、その目
的は、ＦＳＤがファイルシステムのフォーマットを認識
しているか否かを決定すべくボリュームを試験すること
にある。ＦＳ−ＭＯＵＮＴを呼び出すシーケンスは下記
の通りである。 ここで、フラグは、要求された作業を示す。ｆｌａｇ＝
０は、ボリュームをマウント又は受け入れるのにＦＳＤ
が要求されることを示す。ｆｌａｇ＝１は、特定のボリ
ュームが除去されたことをＦＳＤがアドバイスされてい
ることを示す。ｆｌａｇ＝２は、ボリュームがそのドラ
イバから除去されるときに当該ボリュームに割り当てら
れる全ての内部情報及び当該ボリュームが除去されたこ
との最終のカーネル管理リファレンスを開放するのにＦ
ＳＤが要求されることを示す。ｆｌａｇ＝３は、ＦＳＤ
に使用するためのフォーマット化の準備において、認識
の如何に係わらずボリュームを受け入れることをＦＳＤ
が要求されることを示す。他の全てのバリューはリザー
ブされる。ＦＳＤに導かれるバリューは正しいであろ
う。ｐｖｐｆｓｉ−ＶＰＢのファイルシステム独立部分
を指すポインタ。メディアが、オペレーティングシステ
ムの認識可能なブートセクタを収容している場合には、
ファイルされたｖｐｉ ｖｉｄは、ボリュームについて
の３２ビット識別子を収容する。メディアがそのような
ブートセクタを収容しない場合には、ＦＳＤは、メディ
アに対してユニークなラベルを創出して、該ラベルをフ
ァイルされたｖｐｉ ｖｉｄに配置する。ｐｖｐｆｓｄ
−ＶＰＢのファイルシステム従属部分を指すポインタ。
ＦＳＤは、必要に応じ情報をこの領域に記載させること
ができる。 ｈＶＰＢ−ボリュームへのハンドル。 ｐＢｏｏｔ−メディアから読み取られたセクタ０を指す
ポインタ。このポインタは、フラグ＝＝０のときにのみ
正当である。ポインタのバッファは、「ＭＵＳＴ ＮＯ
Ｔ ＢＥ ＭＯＤＩＦＩＥＤ（変更してはならない）」
を指示する。ポインタは常に正当であり、フラグ＝＝０
である場合にはその正当であることを確認する必要はな
い。読取りエラーが生じた場合には、バッファはゼロを
包含する。ＦＳＤは、もたらされたボリュームを試験
し、ボリュームがファイルシステムを認識しているか否
かを決定する。ボリュームがファイルシステムを認識し
ている場合には、ｖｐｆｓｉ及びｖｐｆｓｄの適当な部
分を充填した後に、ゼロに戻る。ｖｐｉ ｖｉｄ及びｖ
ｐｉ ｔｅｘｔのフィールドは、ＦＳＤにより充填され
る。ＦＳＤがオペレーティングシステムのフォーマット
ブートセクタを有している場合には、ＦＳＤは、メディ
アをラベルからａｓｃｌｉｚフォームに変換する。ｖｐ
ｉ ｈＤｅｖのフィールドは、オペレーティングシステ
ムにより充填される。ボリュームが認識されていない場
合には、ドライバは非ゼロ（ｎｏｎ−ｚｅｒｏ）に戻
る。ｖｐｉ ｔｅｘｔ及びｖｐｉ ｖｉｄは、これらの
バリューが変化する度毎により更新されるｖｐｆｓｄの
内容は次の通りである。 ＦＬＡＧ＝０ ＦＳＤはＦＳＤ ＦＩＮＤＤＵＰＨＶＰＢを発行して、
複製ＶＰＢが存在しているか否かを決定する。複製ＶＰ
Ｂが存在している場合には、新しいＶＰＢのｆｓ従属領
域が正しくなく、ＦＳＤがＦＳ＿ＭＯＵＮＴの呼出しか
ら戻った後に、新しいＶＰＢがアンマウントされる。Ｆ
ＳＤは、古いＶＰＢのｆｓ従属領域を更新する。複製Ｖ
ＰＢが存在しない場合には、ＦＳＤは、ｆｓ従属領域を
初期化する。 ＦＬＡＧ＝１ ＶＰＢのｆｓ従属部分は、ＦＳＤが最後にこの従属部分
を変更したものと同じである。 ＦＬＡＧ＝２ ＶＰＢのｆｓ従属部分は、ＦＳＤが最後にこの従属部分
を変更したものと同じである。メディア認識プロセスの
後、ＦＳＨ ＧＥＴＶＯＬＰＡＲＭ呼出しを用いて、ボ
リュームパラメータを試験することができる。ボリュー
ムパラメータは、メディア認識プロセスの後に変更すべ
きではない。マウントリクエストの間、ＦＳＤは、ＦＳ
Ｈ ＤＯＶＯＬＩＯを用いることによりメディアの他の
セクタを試験し、Ｉ／Ｏを行うことができる。不確実メ
ディアの戻りが検出される場合には、ＦＳＤは「ｃｌｅ
ａｎｓｕｐ（クリナップ）」の状態になってＥＲＲＯＲ
ＵＮＣＥＲ−ＴＡＩＮ ＭＥＤＩＡを戻し、新しいイ
ンサートされたメディアに関してボリュームマウント論
理が再スタートできるようにする。ＦＳＤは、付加Ｉ／
Ｏに使用できるバッファを設ける。オペレーティングシ
ステムのカーネルは、上記レフカウント（ｒｅｆｃｏｕ
ｎ）のかウンタを介してＶＰＢを管理する。全てのボリ
ューム特定目的（ｖｏｌｕｍｅｓｐｅｃｉｆｉｃ ｏｂ
ｊｅｃｔｓ）は、適当なボリュームハンドルでラベリン
グされ、ＶＰＢに対する基準を示す。ボリュームに対す
る全てのカーネル基準が消滅すると、フラグ＝２でＦＳ
＿ＭＯＵＮＴが呼び出され、ディスマウントリクエスト
を表示する。ボリュームがそのドライブから除去された
ことをカーネルが検出し、かつ、依然としてボリューム
に対する未解決の基準（ｏｕｔｓｔａｎｄｉｎｇ ｒｅ
ｆｅｒｅｎｃｅｓ）が存在すると、ＦＳ＿ＭＯＵＮＴは
フラグ＝１で呼び出され、ＦＳＤが、ボリュームについ
てのクリーンなデータ（又は、他の再生可能データ）を
記憶できるようにする。ダヒティで再生不可能なデータ
は、該データがドライブ内にリマウントされるときに、
ボリュームに書き込むことができるように保持される。
本発明の目的を得る上で、クリーンデータは変化されな
いデータであり、ダーティなデータは変更されたデータ
である。ＦＳＤに使用できるようにするためボリューム
をフォーマット化すべきときには、オペレーティングシ
ステムのカーネルは、フラグ＝３でＦＳＤのＦＳ＿ＭＯ
ＵＮＴ入口を呼び出し、ＦＳＤがフォーマット作業の準
備を行えるようにする。ＦＳＤは、ボリュームがＦＳＤ
の認識するボリュームでない場合でもボリュームを受け
入れる。フォーマットがボリュームに関してファイルシ
ステムを変化させるからである。フォーマット化を完了
できない場合（例えば、ＦＳＤがＣＤ−ＲＯＭのサポー
トする場合）には、作業は失敗するであろう。殆どのコ
ンピュータシステムのハードウェアは、メディアのカー
ネルメディア形除去（Ｋｅｒｎｅｌ−ｍｅｄｉａｔｅｄ
ｒｅｍｏｖａｌ ｏｆ ｍｅｄｉａ）ができないの
で、ボリュームがどのドライブにも存在しないときにア
ンマウントリクエストが発行されることは確実である。
ＦＳＨ＿ＤＯＶＯＬＩＯは、特定のボリュームに対する
Ｉ／Ｏを実行する。ＦＳＨ＿ＤＯＶＯＬＩＯは、リクエ
ストされたＩ／Ｏに対するデバイスドライバのリクエス
トパケットをフォーマット化し、デバイスドライバを呼
出し、かつＦＳＤに戻る前に、あらゆるエラーをハード
エラーダエモンに報告する。ハードエラーダエモンによ
り表示された全ての再試行（ｒｅｔｒｉｅｓ）又はＤＯ
ＳＥＲＲＯＲにより表示されたアクションは、ＦＳＨ＿
ＤＯＶＯＬＩＯへの呼出しを行っている間に行われる。
次に、ＦＳＨ＿ＤＯＶＯＬＩＯに対する呼出しフォーマ
ットについて説明する。 ここで、オペレーションビットマスク（ｏｐｅｒａｔｉ
ｏｎ ｂｉｔ ｍａｓｋ）は、実行すべきｒｅａｄ／ｒ
ｅａｄ−ｂｙｐａｓｓ／Ｗｒｉｔｅ／Ｗｒｉｔｅ−ｂｙ
ｐａｓｓ／ｖｅｒｉｆｙ−ａｆｔｅｒ−ｗｒｉｔｅ／ｗ
ｒｉｔｅ−ｔｈｒｏｕｇｈ及びノーキャッシュ作業（ｎ
ｏ−ｃａｃｈｅ ｏｐｅｒａｔｉｏｎ）を表示する。 Ｂｉｔ ０×０００１ ｏｆｆは、読取りを表示する。 Ｂｉｔ ０×０００１ ｏｎは、書込みを表示する。 Ｂｉｔ ０×０００２ ｏｆｆは、ｎｏ−ｂｙｐａｓｓ
を表示する。 Ｂｉｔ ０×０００２ ｏｎは、ｃａｓｃｈｅ ｂｙｐ
ａｓｓを表示する。 Ｂｉｔ ０×０００４ ｏｆｆは、ｎｏ ｖｅｒｉｆｅ
ｙ−ａｆｔｅｒ−ｗｒｉｔｅ作業を表示する。 Ｂｉｔ ０×０００４ ｏｎは、ｖｅｒｉｆｙ−ａｆｔ
ｅｒ−ｗｒｉｔｅを表示する。 Ｂｉｔ ０×０００８ ｏｆｆは、ハードエラーダエモ
ンに信号を送られたエラーを表示する。 Ｂｉｔ ０×０００８ ｏｎは、ハードエラーが直接戻
されることを表示する。 Ｂｉｔ ０×０００１０ ｏｆｆは、Ｉ／Ｏが“ｗｒｉ
ｔｅ−ｔｈｒｏｕｇｈ”でないことを表示する。 Ｂｉｔ ０×０００１０ ｏｎ は、このＩ／Ｏが“ｗ
ｒｉｔｅ−ｔｈｒｏｕｇｈ”であることを表示する。 Ｂｉｔ ０×０００２０ ｏｆｆは、このＩ／Ｏに対す
るデータを変更すべきことを表示する。 Ｂｉｔ ０×０００２０ ｏｎ は、このＩ／Ｏに対す
るデータを変更すべきではないことを表示する。 リザーブされた他の全てのビットはゼロである。「ｃａ
ｃｈｅ ｂｙｐａｓｓ（キャッシュバイパス）」と、
「ｎｏ ｃａｃｈｅ（のキャッシュ）」ビットとの間の
相違は、リクエストパケットの形式においてデバイスド
ライバが導かれることである。「ｃａｃｈｅ ｂｙｐａ
ｓｓ」では、コマンドコード２４、２５又は２６でパケ
ットが得られ、「ｎｏ ｃａｃｈｅ」では、システム
は、コマンドコード４、８又は９に対するバケットを拡
大する。 ｈＶＰＢ Ｉ／Ｏの資源に対するボリュームハンド
ル。 ｐＤａｔａ ユーザの転送領域（ｔｒａｎｓｆｅｒ
ａｒｅａ）の長いアドレス。 ｐｃＳｅｃ 転送すべきセクタ数を指すポインタ。 戻り時には、これは首尾良く転送されたセクタ数であ
る。 ｉＳｅｃ 転送の最初のセクタ数。 Ｒｅｔｕｒｎｓ −作業が失敗した場合には、０以外の
エラーコード。ＥＲＲＯＲ ＰＲＯＪＥＣＴＩＯＮ Ｖ
ＩＯＬＡＴＩＯＮ−供給されたａｄｄｒｅｓｓ／ｌｅｎ
ｇｔｈは正しくない。ＥＲＲＯＲ ＵＮＣＥＲＴＡＩＮ
ＭＥＤＩＡ−メディアが変更されているときには、デ
バイスドイバは信頼性をもって告げることはできない。
このことは、ＦＳ ＭＯＵＮＴのコンテクスト内におい
てのみ生じる。ＥＲＲＯＲ ＴＲＡＮＳＦＥＲ ＴＯＯ
ＬＯＮＧ−デバイスにとって転送が非常に短い。ＦＳ
Ｈ＿ＤＯＶＯＬＩＯは、常時、ＦＳＤ内で使用すること
ができる。ＦＳ＿ＭＯＵＮＴ呼出しの範囲内で呼び出さ
れるとき、ＦＳＨ＿ＤＯＶＯＬＩＯは、ボリュームの如
何に係わらず、ドライブのボリュームに適用される。し
かしながら、ＦＳＤがＦＳ＿ＭＯＵＮＴの呼出しに戻る
までは、ボリュームの認識が完了しないので、ＦＳＤ
は、ＥＲＲＯＲ ＵＮＣＥＲＴＡＩＮ ＭＥＤＩＡが戻
されないときには、特別な注意を払わなければならな
い。これは、ドライブにおけるメディアを識別するの
に、メディアが不確実な試みを行ったことを表示する。
また、ＦＳＤが認識を試みたポリュームが除去されたこ
とを表示するようにしてもよい。この場合、ＦＳＤは、
ＦＳ ＭＯＵＮＴの呼出し時に導かれたｈＶＰＢに取り
付けられたあらゆる資源を解放し、かつＥＲＲＯＲ Ｕ
ＮＣＥＲＴＡ−ＩＮＭＥＤＩＡをＦＳ＿ＭＯＵＮＴ呼出
しに戻す。これにより、マウントプロセスを再スタート
させるように、ボリュームトラッキング論理を仕向けら
れる。ＦＳＤｓは、ＦＳＨ ＤＯＶＯＬＩＯ２を呼出し
て、Ｉ／Ｏ作業とは独立して、デバイスドライバの作業
を制御する。このルーチンは、ＩＯＣＴＬ作業に対する
ボリューム管理をサポートしている。ＦＳＤに戻る前
に、全てのエラーがハードエラーダエモンに報告され
る。ハードエラーダエモンにより表示されるすべての再
試行又はＤＯＳＥＲＲＯＲにより表示されるアクション
は、ＦＳＨ ＤＯＶＯＬＩＯ２への呼出し内に行われ
る。 ここで、 ｈＤｅｖ−ＶＰＢから得られたデバイスハンドル。 Ｓｆｎ−ＦＳＨ ＤＥＶＩＯＣＴＬ呼出しを引き起こし
たオープンインスタンス（ｏｐｅｎ ｉｎｓｔａｎｃ
ｅ）からのシステムファイルの数。このフィールドは、
変化されない状態で、ｓｆｉ ｓｅｌｆｓｆｎのフィー
ルドから導かれるべきである。どのオーブンインスタン
スもこの呼出しに一致しないときには、このフィールド
は、０×ＦＦＦＦに設定される。 ｃａｔ −実行すべきＩＯＣＴＬのカテゴリ。 ｆｕｎｃ−ＩＯＣＴＬのカテゴリ内での機能。 ｐＰａｒｍ−パラメータ領域へのロングアドレス。 ｃｂＰａｒｍ−パラメータ領域の長さ。 ｐＤａｔａ−データ領域へのロングアドレス。 ｃｂＤａｔａ−データ領域の長さ。 Ｒｅｔｕｒｎｓ−エラーが検出されないときには０以外
のエラーコード。 供給された機能が、ここに述べているシステムとの互換
性をもたない場合には、ＥＲＲＯＲ ＩＮＶＡＬＩＤ
ＦＵＮＣＴＩＯＮが呼び出される。メディアが不確実に
なるときにはいつでも、新しいＶＰＢが割り当てられる
（メディアが変更されていないことがもはや確かではな
いことを、デバイスドライバは認識している）。このＶ
ＰＢは、ＦＳ ＭＯＵＮＴ呼出しが戻るまで、（メディ
アの再インサートにより）前に割り当てられたＶＰＢと
共に崩壊することはない。しかしながら、前のＶＰＢ
は、メディア（このメディアは、該メディアが除去され
ている間に書き込むことができる）から更新されなくて
はならない幾つかのキャッシュデータをもつことができ
る。古いＶＰＢについてのキャッシュ情報（ｃａｃｈｅ
ｄ ｉｎｆｏｒｍａｔｉｏｎ）を更新するため、ＦＳＨ
ＦＩＮＤＤＵＰＨＶＰＢは、ボリュームの、この前に
生じたことをＦＳＤが見出すことを可能にする。このボ
リュームについて別の古いＶＰＢが存在しない場合に
は、新しい創出されたＶＰＢがアンマウントされる。Ｆ
ＳＨ ＦＩＮＤＤＵＰＨＶＰＢについての呼出しフォー
マットは次の通りである。 ここで、 ｈＶＰＢ−見出すべきボリュームに対するハンドル。 ｐｈＶＰＢ−マッチングボリュームのハンドルをどこに
記憶させるかを指すポインタ。 Ｒｅｔｕｒｎｓ−マッチングＶＰＢが見出されないとき
には０以外のエラーコード。 ＥＲＲＯＲ ＮＯ ＩＴＥＭＳ−マッチングｈＶＰＢは
存在しない。ＦＳＨ ＧＥＴＶＯＬＰＡＲＭは、ＦＳＤ
が、ＶＰＢからファイルシステムの独立及び従属データ
を検索することを可能にする。ＦＳルータはＶＰＢハン
ドル内を通るので、ここのＦＳＤｓは、適合部分を指す
ポインタ内にハンドルをマッピングする。ＦＳＨ ＧＥ
ＴＶＯＬＰＡＲＭについての呼出しシーケンスは次の通
りである。 ここで、 ｈＶＰＢ−関心のあるボリュームハンドル。 ｐｐＶＰＢｆｓｉ−ファイルシステムの独立データを記
憶させるべくポインタが指す位置。 ｐｐＶＰＢｆｓｄ−ファイルシステムの従属データを記
憶させるべくポインタが指す位置。 Ｒｅｔｕｒｎｓ−なし。 ＦＳＤ Ｖｏｌｕｍｅのマッピングはダイナミックであ
り、かつＦＳＤ−ＤＤ連結は、ＦＳＤ及びＤＤの独立方
法により、オペレーティングシステムのカーネルを介し
て行われるので、あらゆるＦＳＤは、ＤＤｓがこのＦＳ
Ｄからローディングされたボリュームを含むあらゆるボ
リュームにアクセスできる。ボリュームは、除去可能な
メディアの特定のピース（片）、又は区分できる任意の
メディアの任意の区分にマッビングするので、多数のＦ
ＳＤｓが特定のハードディスク又は他のメディアにアク
セスできるようにしてもよい。ボリュームファイル作業
は、２つのカテゴリ、すなわち、ネームベース作業（ｎ
ａｍｅｄ−ｈａｓｅｄ ｏｐｅｒａｔｉｏｎｓ）及びハ
ンドルベース作業（ｈａｎｄｌｅ−ｂａｓｅｄ ｏｐｅ
ｒａｔｉｏｎｓ）に分けることができる。ネームベース
作業は一般にユーザによって開始され、システム１００
がファイルについてネーム作業を行うことをユーザがシ
ステム１００に命令（ｉｎｓｔｒｕｃｔ）する。ハンド
ルベース作業は、一般に、システムのバックグラウンド
作業中に開始される。通常、ハンドルベース作業は、ネ
ームベース作業の後に行われる。図１７に示すように、
コンピュータシステム１００がネームベース作業を行っ
ているときに、ルーチン８００が呼び出される。ネーム
ド作業は、文字ネームにより指示された作業である。す
なわち、この作業は、ファイル又はディレクトリのネー
ムにより特定化される。「Ｏｐｅｎ ｆｉｌｅ“ｘｘ
ｘ”」はネームベース作業の一例である。プロセス８０
２は、ネームをパーシング（ｐａｒｓｅ）すべく呼び出
されて、３つの変数すなわち、ＰａｔｈＮａｍｅＴｙｐ
ｅ、ＴＣＢＴｈｉｓｈＶＰＢ及びＴＣＢＴｈｉｓＦＳＣ
を戻す。このプロセス８０２については、図１８に関連
して詳細に説明する。（注、ｈはハンドルをいい、ＴＣ
Ｂは、ＴＣＨＴｈｉｓｈＶＰＢが現に関心をもっている
ＶＰＢへのハンドルでありかつＴＣＢＴｈｉｓＦＣＨが
関心のあるファイルシステムを指すポインタである、ス
レッド制御ブロック（ｔｈｒｅａｄ ｃｏｎｔｒｏｌ
ｂｌｏｃｋ）いう。）次に、項目８０４は、プロセス８
０２により戻された変数ＰａｔｈＴｙｐｅ、ＴｃｈＴｈ
ｉｓｈＶＰＢ及びＴＣＨＴｈｉｓＦＣＨに基づく適当な
機能に制御をルーチング（ｒｏｕｔｅ）する。ＵＮＣ
ＦＳＤが呼び出されるユニバーサルネーミングコンベン
ション（Ｕｎｉｖｅｒｓａｌ Ｎａｍｉｎｇ Ｃｏｎｖ
ｅｎｔｉｏｎ、「ＵＮＣ」）のグローバルネットワーク
を表示する「＼＼」で経路（ｐａｔｈ）が始まるときに
は、項目８０６を通る制御が行われる。ローカル装置が
表示される場合には、制御が項目８０８に導かれ、カー
ネル内でリクエストが処理される。疑似装置又は遠隔フ
ァイルが表示されるときには、制御は項目８１０に導か
れて、疑似装置又は遠隔ファイルが取り付けられた遠隔
ＦＳＤに対するリクエストをルーチングする。ネームド
パイプ（ｎａｍｅｄ ｐｉｐｅ）が検出された場合に
は、制御は項目８１２に導かれて、カーネル無しでロー
カルネームドパイプコードを呼び出す。ローカルファイ
ルが表示される場合には、制御は項目８１４に導かれ
る。この項目８１４は、項目８１６におけるＦＳＨＤＯ
ＶＯＬＩＯを呼び出すことによりボリュームへの読取り
及び書込みを行うＦＳＤにおけるＦＳＤワーカである。
ＦＳＨＤＯＶＯＬＩＯについては、図２０に関して更に
詳細に説明する。次に、図１８を参照して、パーシング
プロセス８０２を説明する。呼出しがあると、項目９０
２は、現在のドライブ、現在のディレクトリ及びネーム
自体に基づいて、関心のあるネームをカノニカルフォー
ム（ｃａｎｏｎｊａｌ ｆｏｒｍ）に変形する。次に、
変数ＴＣＢＴＨＩＳＦＳＣ、ＴＣＨＴｈｉｓＶＰＢ及び
ｐａｔｈｎａｍｅｔｙｐｅが下記のようにして決定され
るデシジョン９０４は、ユーザのネームが「＼＼」で始
まっているか否かを決定して、ＵＮＣネームが表示され
ているか否かを決定する。ＵＮＣネームが表示されてい
れば、制御が項目９０５に導かれ、ここで、変数ｐａｔ
ｈｔｙｐｅ、ＴｃｈＴｈｉｓｈＶＰＢ及びＴＣＢＴｈｉ
ｓＦＣＨが初期化され、ユーザのネームを適当な位置に
ルーチングする。ＵＮＣネームが表示されていなけれ
ば、デシジョン９０６は、関心をもつネームがカーネル
により維持された、装置のネームリストに載ったネーム
であるか否かを決定する。装置のネームリストに載った
ネームであるときには、デシジョン９０８は、それが疑
似文字装置であるか否かを決定する。疑似文字装置であ
れば、項目９１０は表示のように変数を設定する。疑似
文字装置でないときは、制御９１２に導かれ、表示のよ
うに変数を設定する。デシジョン９１４は、ネームの初
めにおける「＼ｐｉｐｅ＼」を探すことにより、そのネ
ームが、ネームドパイプであるか否かを決定する。その
ネームがネームドパイブであるときは、項目９１６は、
表示のように変数を設定する。ネームドパイブでないと
きは、デシジョン９１８は、そのネームがローカルドラ
イブ又は遠隔ドライブのパスネーム（ｐａｔｈｎａｍ
ｅ）を表示しているか否かを決定する。遠隔ドライブが
表示されているときは、制御は項目９２０に導かれ、こ
こでは、表示のように変数ＰａｔｈＴｙｐｅ、ＴｃｈＴ
ｈｉｓｈＶＰＢ及びＴＣＢＴｈｉｓＦＣＨを設定する。
遠隔ドライブが表示されていないときは、制御は項目９
２２に導かれ、ここでは、どのボリュームから適当なデ
ータを読み取るかが呼び出される。ＷｈａｔＶｏｌｕｍ
ｅが戻ると、制御は項目９２４に導かれ、ここでは、表
示のように変数ＰａｔｈＴｙｐｅ、ＴｃｈＴｈｉｓｈＶ
ＰＢ及びＴＣＢＴｈｉｓＦＣＨが設定される。図１９を
参照すると、プロセス１０００が呼び出され、ハンドル
ベース作業が行われる。呼出し時に、項目１００２はＳ
ＦＴ入口を検索する。ＳＦＴ入口及びハンドルは、両方
共ＤｏｓＯｐｅｎにより設定される。次いで、ＴＣＢＴ
ｈｉｓＦＳＣが表示のように設定される。次に、項目１
００４において、ＦＳＣが指示するファイルシステムの
適合ＦＳＤワーカが呼び出される。次いで、項目１００
６は、項目１０１６を呼び出し、必要に応じて項目１０
１６を呼び出すことにより、呼び出し者すなわちコーラ
ー（ｃａｌｌｅｒ）によりリクエストされたあらゆるＩ
／Ｏを実行する。図２０には、ＦＳＨ Ｄｏ Ｖｏｌ
１０が示されている。項目１１０２において呼出しがな
されると、ｈＶＰＢが使用されて、ドライブ並びに関心
のあるボリュームにどのようなボリュームがあるかを決
定する。次に、デシジョン１１０４は、ドライブにおけ
るボリュームが関心のあるボリュームであるか否かを決
定する。関心のあるボリュームであるときは、項目１１
０６が呼び出されて、デバイスドライバが呼び出されか
つ特定のパラメータでＩ／Ｏを実行する。次にデシジョ
ン１１０８は、作業中にメディアが不確実に移行したか
否かを決定する。不確実に移行していないときには、プ
ロセスは項目１１１４に戻る。デシジョン１１０８が、
メディアは不確実ではないことを決定するときには、制
御は項目１１１２に導かれ、ここでは、ＷｈａｔＶｏｌ
ｕｍｅが呼び出されてメディアが確実なものにされる。
次いで、制御はデシジョン１１０４に戻る。ドライブに
おけるボリュームが関心のあるボリュームに一致しない
ときには、項目１１１０が呼び出されて、ＨａｒｄＥｒ
ｒｏｒが呼び出され、ドライブに正しいドライブを置く
ことをユーザに知らせる。次に制御は上記項目１１１２
に導かれる。付録（Ａｐｐｅｎｄｉｘ）ＩＩからＶＩ
は、設置可能なファイルシステムの資源の一例としてこ
こに包含される。ここで、付録ＩＩは、本発明の教示に
従ってサポートすることが期待されるファイルシステム
の移出インターフェース（ｅｘｐｏｒｔｅｄ ｉｎｔｅ
ｒｆａｃｅｓ）のリストである。付録ＩＩＩは、ファイ
ルシステムを用いることができるカーネルにより移出さ
れるインターフェースのリストである。付録ＩＶは、本
発明に従って構成された設置可能なファイルシステムの
一例の資源コードである。付録Ｖは、付録ＩＶのＦＳＤ
を作るべくＯＳ／２により用いられる定義ファイル（ｄ
ｅｆｉｎｉｔｉｏｎｓ ｆｉｌｅ）のリストである。付
録ＶＩは付録ＩＶのＩＦＳにより使用される構成とパラ
メータを限定しているヘッダーファイルである。付録Ｖ
ＩＩは本発明の高性能ファイルシステムを実現するのに
使用するディスク構成の詳細なリストである。要約し
て、データをボリューム内に編成するための改良型高性
能ファイルシステムを説明した。本発明の原理によれ
ば、第１のディスク フィールドがブートブロックを備
え、この第１のフィールドにつづく第２のフィールドが
スーパーブロックを備え、この第２のフィールドに続く
第３のフィールドはスペアブロックを備え、そして複数
のバンドがデータを記憶するための一連の連続セクタを
含み、各バンドはセクタ使用を示すフリースペースビッ
トマップを含んでいる、ディスクの一連のフィールドに
データを編成する。フリースペースビットマップはバン
ドの始めか終わりにあって、交互のバンドのためのビッ
トマップは相互に隣接している。ブートブロックはボリ
ュームネーム、ボリュームＩ．Ｄ．そしてディスクブー
トストラッププログラムを含んでいる。スーパーブロッ
クはフリースペースビットマップ、バッドブロックリス
ト、ディクショナリブロックバンド、そしてルートディ
クショナリへのポインタを含んでいる。本発明に従って
ファイルとディクショナリとはＦノード構成にアンカー
されている。Ｆノード構成はセクタの続きを指している
複数のポインタを備えている。他の使用や変形は当業者
には自明のことであろう。このような使用や変形は本発
明の思想に含まれるものである。
【発明の効果】従って、本発明によれば、ファイルシス
テムの形式及びフォーマットの如何に拘わらず、適当な
ファイルシステムに不確実メディアを自動的にかつダイ
ナミックにマッピングする方法及び手段が提供される。
テムの形式及びフォーマットの如何に拘わらず、適当な
ファイルシステムに不確実メディアを自動的にかつダイ
ナミックにマッピングする方法及び手段が提供される。
【図１】本発明の原理に従って構成されたコンピュータ
システムのブロックダイアグラムである。
システムのブロックダイアグラムである。
【図２】図１のコンピュータシステムの作業及びファイ
ルシステムアーキテクチュアを示すブロックダイアグラ
ムである。
ルシステムアーキテクチュアを示すブロックダイアグラ
ムである。
【図３】ＭＳ−ＤＯＳオペレーティングシステムのファ
イルシステム構成の詳細を示すブロックダイアグラムで
ある。
イルシステム構成の詳細を示すブロックダイアグラムで
ある。
【図４】本発明の設置可能なファイルシステムのファイ
ルシステム構成の詳細を示すブロックダイアグラムであ
る。
ルシステム構成の詳細を示すブロックダイアグラムであ
る。
【図５】図４のファイルシステムのより詳細なブロック
ダイアグラムである。
ダイアグラムである。
【図６】ＦＡＴフィルタシステムのディクフォーマット
を示すブロックダイアグラムである。
を示すブロックダイアグラムである。
【図７】本発明に使用できるように構成された設置可能
なファイルシステムのディスクフォーマットを示すブロ
ックダイアグラムである。
なファイルシステムのディスクフォーマットを示すブロ
ックダイアグラムである。
【図８】本発明に使用できるように構成された設置可能
なファイルシステムのディスクフォーマットを示す他の
ブロックダイアグラムである。
なファイルシステムのディスクフォーマットを示す他の
ブロックダイアグラムである。
【図９】本発明に使用できるように構成された設置可能
なファイルシステムのディスクフォーマットを示す別の
ブロックダイアグラムである。
なファイルシステムのディスクフォーマットを示す別の
ブロックダイアグラムである。
【図１０】本発明に使用できるように構成された設置可
能なファイルシステムのディスクフォーマットを示す更
に別のブロックダイアグラムである。
能なファイルシステムのディスクフォーマットを示す更
に別のブロックダイアグラムである。
【図１１】本発明に使用できるように構成された設置可
能なファイルシステムのディスクフォーマットを示す他
のブロックダイアグラムである。
能なファイルシステムのディスクフォーマットを示す他
のブロックダイアグラムである。
【図１２】本発明に使用できるように構成された設置可
能なファイルシステムのディスクフォーマットを示す別
のブロックダイアグラムである。
能なファイルシステムのディスクフォーマットを示す別
のブロックダイアグラムである。
【図１３】本発明に使用できるように構成された設置可
能なファイルシステムのディスクフォーマットを示す他
のブロックダイアグラムである。
能なファイルシステムのディスクフォーマットを示す他
のブロックダイアグラムである。
【図１４】本発明に使用できるように構成された設置可
能なファイルシステムのディスクフォーマットを示す更
に別のブロックダイアグラムである。
能なファイルシステムのディスクフォーマットを示す更
に別のブロックダイアグラムである。
【図１５】本発明のマウントプロセスの全作業の詳細を
示すフローチャートである。
示すフローチャートである。
【図１６】本発明の設置可能なファイルシステムの構成
を示すブロックダイアグラムである。
を示すブロックダイアグラムである。
【図１７】本発明の原理に従がうネームベース作業の実
行の詳細を示すフローチャートである。
行の詳細を示すフローチャートである。
【図１８】ネームベース作業プロセスにより呼び出され
るパーシングプロセスを示すフローチャートである。
るパーシングプロセスを示すフローチャートである。
【図１９】本発明の原理に従がうハンドルベース作業を
示すフローチャートである。
示すフローチャートである。
【図２０】図１７及び図１９に関連して説明したプロセ
スにより呼び出されＦＳＨ ＤｏＶｏｌＩｏプロセスを
示すフローチャートである。
スにより呼び出されＦＳＨ ＤｏＶｏｌＩｏプロセスを
示すフローチャートである。
１００ コンピュータシステム １０２ マイクロプーセッサ １０４ ランダムアクセスメモリ １０６ リードオンリメモリ １０８ マウス １１０ キーボード １１２ ディスプレイ １１４ プリンタ １１６ フロッピディスクドライプ １２０ ハードディスクドライブ １２２ ＣＤ−ＲＯＭドライブ １２４ テープドライブ １２６ ネットワーク
Claims (26)
- 【請求項１】 メモリが複数のバンドから構成されてお
り、各該バンドが複数のセクタから構成されており、各
該セクタが複数のメモリロケーションから構成されてい
る該メモリのアロケーションをトラッキングするための
コンピュータシステムにおけるトラッキング方法であっ
て、各ビットマップがバンド内の各セクタについてビッ
トを有しており、前記複数のバンドのそれぞれについて
該ビットマップをアロケーティングし、メモリのセクタ
をアロケーティングするときに、セクタがアロケートさ
れたことを示すべくセクタを包含するバンドのビットマ
ップにビットを設定し、メモリのセクタをディアロケー
ティングするときに、セクタがディアロケートされたこ
とを示すべくセクタを包含するバンドのビットマップに
ビットを設定する段階を具備することを特徴とするトラ
ッキング方法。 - 【請求項２】 前記ビットマップをアロケーティングす
る段階は、更に、ビットマップのアロケーションについ
て各バンドに最も近いメモリの部分を選択する段階を含
むことを特徴とする請求項１に記載のトラッキング方
法。 - 【請求項３】 前記ビットマップをアロケーティングす
る段階は、更に、論理的に連続するバンドの組について
のビットマップは、論理的に連続するメモリロケーショ
ンにアロケートされるように、メモリの部分を選択する
段階を含むことを特徴とする請求項１に記載のトラッキ
ング方法。 - 【請求項４】 前記ビットマップをアロケーティングす
る段階は、更に、２つのビットマップは、交互バンド間
の隣接するメモリロケーションにアロケートされるよう
に、ビットマップのアロケーションについて各バンドの
ヘッド又はテールでメモリの部分を選択する段階を含む
ことを特徴とする請求項１に記載のトラッキング方法。 - 【請求項５】 ２つの論理的に連続するバンドから１つ
のファイルに論理的に連続するセクタのグループをアロ
ケーティングし、グループの第１のセクタの指示子及び
最後のセクタの指示子によって論理的に連続するセクタ
のグループを識別する段階を含むことを特徴とする請求
項３又は４に記載のトラッキング方法。 - 【請求項６】 コンピュータシステムが複数のメモリロ
ケーションを伴うメモリを有しており、ファイルにメモ
リロケーションのアロケーションをトラッキングするた
めのコンピュータシステムにおけるトラッキング方法で
あって、ファイル Ｆｎｏｄｅがファイルにアロケート
された論理的に連続するメモリロケーションの変数−長
さ走行の指示子を記憶するメモリロケーションを有して
おり、該ファイルＦｎｏｄｅについてメモリロケーショ
ンをアロケーティングし、論理的に連続するメモリロケ
ーションの複数の変数−長さ走行をファイルにアロケー
ティングし、ファイルにアロケートされた各走行につい
て、ロケーション及び走行の長さを識別すべくファイル
Ｆｎｏｄｅに指示子を設定する段階を具備することを特
徴とするトラッキング方法。 - 【請求項７】 メモリロケーションの部分がファイルに
アロケートされた走行の指示子を記憶しており、走行の
数が走行の指示子を記憶するためのファイルＦｎｏｄｅ
の許容量を越えたときに、ファイルＦｎｏｄｅにメモリ
ロケーションの部分を指しポインタを記憶する段階を含
むことを特徴とする請求項６に記載のトラッキング方
法。 - 【請求項８】 前記ファイルＦｎｏｄｅに指示子を設定
する段階は、木構造に指示子を記憶する段階を含むこと
を特徴とする請求項６に記載のトラッキング方法。 - 【請求項９】 前記木構造は、Ｂ＋木であることを特徴
とする請求項８に記載のトラッキング方法。 - 【請求項１０】 ファイルサイズの増加を示すべくファ
イルの最後の走行の長さを増加する段階を含むことを特
徴とする請求項６または９に記載のトラッキング方法。 - 【請求項１１】 ファイル内の論理的な位置をアクセス
するときに、論理的なファイル位置のメモリ位置を決定
すべく該ファイルの複数の走行の長さを合計することを
特徴とする請求項６または９に記載のトラッキング方
法。 - 【請求項１２】 記憶装置アロケーションをトラッキン
グするコンピュータシステムであって、各バンドが複数
のセクタを有し、各セクタが複数の記憶位置を有する、
複数のバンドを有する記憶装置と、各該ビットマップが
該バンド内の各セクタについてビットを有しており、前
記複数のバンドのそれぞれについてビットマップをアロ
ケーティングする手段と、セクタがアロケートされたこ
とを示すべくセクタを包含するバンドのビットマップに
ビットを設定する手段と、セクタがディアロケートされ
たことを示すべくセクタを包含するバンドのビットマッ
プにビットを設定する手段とを備えることを特徴とする
コンピュータシステム。 - 【請求項１３】 ビットマップのアロケーションについ
て各バンドに近い記憶位置を選択する手段を含むことを
特徴とする請求項１２に記載のコンピュータシステム。 - 【請求項１４】 論理的に連続するバンドの組について
のビットマップは、論理的に連続する記憶位置にアロケ
ートされるように、記憶位置を選択する手段を含むこと
を特徴とする請求項１２に記載のコンピュータシステ
ム。 - 【請求項１５】 ２つのビットマップは、交互バンド間
の隣接する記憶位置にアロケートされるように、ビット
マップのアロケーションについて各バンドのヘッド又は
テールで記憶位置を選択する手段を含むことを特徴とす
る請求項１２に記載のコンピュータシステム。 - 【請求項１６】 １つのファイルに２つの論理的に連続
するバンドから論理的に連続するセクタのグループをア
ロケーティングする手段と、グループの第１のセクタの
指示子及び最後のセクタの指示子によって論理的に連続
するセクタのグループを識別する手段とを含むことを特
徴とする請求項１４又は１５に記載のコンピュータシス
テム。 - 【請求項１７】 ファイルにメモリロケーションのアロ
ケーションをトラッキングするコンピュータシステムで
あって、複数のメモリロケーションを伴うメモリと、フ
ァイルノードについてメモリロケーションをアロケーテ
ィングする手段と、該ファイルノードがファイルにアロ
ケートされた論理的に連続するメモリロケーションの変
数−長さ走行の指示子を記憶するメモリロケーションを
有しており、論理的に連続するメモリロケーションの複
数の変数−長さ走行をファイルにアロケーティングする
手段と、走行のロケーション及び長さを識別すべくファ
イルノードに指示子を設定する手段とを備えることを特
徴とするコンピュータシステム。 - 【請求項１８】 走行の数が、走行の指示子を記憶する
ためのファイルノードの許容量を越えたときに、ファイ
ルノードにメモリロケーションの標識を記憶する手段、
該部分がファイルにアロケートされた走行の指示子を記
憶する、を含むことを特徴とする請求項１７に記載のコ
ンピュータシステム。 - 【請求項１９】 木構造に前記指示子を記憶する手段を
含むことを特徴とする請求項１７に記載のコンピュータ
システム。 - 【請求項２０】 Ｂ＋木に前記指示子を記憶する手段を
含むことを特徴とする請求項１７に記載のコンピュータ
システム。 - 【請求項２１】 ファイルサイズの増加を示すべくファ
イルの最後の走行の長さを増加する手段を含むことを特
徴とする請求項１７、１８、１９または２０に記載のコ
ンピュータシステム。 - 【請求項２２】 ファイル内の論理的な位置をアクセス
するときに、論理的なファイル位置のメモリ位置を決定
すべく該ファイルの複数の走行の長さを合計する手段を
含むことを特徴とする請求項１７、１８、１９または２
０に記載のコンピュータシステム。 - 【請求項２３】 ファイル記憶装置上のディレクトリ階
層を維持するコンピュータシステムにおける方法であっ
て、各ディレクトリについて、ディレクトリ構造を指す
ポインタを有するディレクトリ Ｆｎｏｄｅを割当
て、それぞれがファイル Ｆｎｏｄｅ又はディレクトリ
Ｆｎｏｄｅを指すポインタを有する複数のディレクトリ
エントリからなるディレクトリ構造を割当てる段階を具
備することを特徴とする方法。 - 【請求項２４】 記憶装置に階層的方法でファイルを編
成するコンピュータシステムにおける方法であって、前
記ファイルの階層は、複数のディレクトリ及びファイル
からなり、前記記憶装置は、複数の論理的に連続なセク
タを有し、前記各セクタは、複数の論理的に連続なロケ
ーションを有しており、前記方法は、前記記憶装置の記
述的なブロック部分を割当て、各ディレクトリについ
て、該ディレクトリに関する情報を記憶するための記憶
装置のディレクトリ部分を割当て、各ファイルについ
て、該ファイルに関する情報を記憶するための記憶装置
のファイル部分を割当てる段階を具備しており、該記述
的なブロック部分は、ファイルシステム情報部分及びセ
クタ割当て部分を有し、該ファイルシステム情報部分
は、ルートディレクトリを指すポインタを有し、該セク
タ割当て部分は、該セクタの割当てを記述している情報
を包含しており、該ディレクトリ部分は、ディレクトリ
Ｆｎｏｄｅ部分及びディレクトリブロック部分を有し、
該ディレクトリＦｎｏｄｅ部分は、該ディレクトリを記
述している情報を包含し、該ディレクトリブロック部分
は、該ディレクトリ内に各ディレクトリを記述している
エントリ及びファイルを包含しており、前記ファイル部
分は、ファイルＦｎｏｄｅ 部分及びデータ部分を有
し、該ファイル Ｆｎｏｄｅ部は、該ファイルを識別
する情報及び複数の実行標識を包含し、各該実行標識
は、複数の論理的に連続なロケーションの実行を識別
し、該データ部分は、複数の実行からなることを特徴と
する方法。 - 【請求項２５】 ディレクトリ階層を維持するコンピュ
ータシステムであって、ファイル記憶装置と、前記ファ
イル記憶装置内の第１のディレクトリ構造を割当てる手
段と、前記ファイリ記憶装置内の第２のディレクトリ構
造を割当てる手段とを備えており、各前記第１のディレ
クトリは、第２のディレクトリ構造を指すポインタを有
し、該第２のディレクトリ構造は、複数のディレクトリ
エントリからなり、各該ディレクトリエントリは、ファ
イル又はディリクトリの標識を有して、該第１のディレ
クトリ構造及び該第２のディレクトリ構造がディレクト
リ階層を形成することを特徴とするコンピュータシステ
ム。 - 【請求項２６】 階層的方法でファイルを編成するコン
ピュータシステムであって、ファイルの階層は、複数の
ディレクトリ及びファイルからなり、前記コンピュータ
システムは、それぞれが複数の論理的に連続なロケーシ
ョンを有する複数の論理的に連続なセクタを有する記憶
装置と、前記記憶装置の記述的なブロック部分を割当て
る手段と、前記ディレクトリに関する情報を記憶するた
めの記憶装置のディレクトリ部分を割当てる手段と、前
記ファイルに関する情報を記憶するための記憶装置のフ
ァイル部分を割当てる手段とを備えており、前記記述的
なブロック部分は、ファイルシステム情報部分及びセク
タ割当て部分を有し、該ファイルシステム情報部分は、
ルートディレクトリの標識を有し、該セクタ割当て部分
は、セクタの割当てを記述する情報を包含しており、該
ディレクトリ部分は、ディレクトリノード部分及びディ
レクトリブロック部分を有し、該ディレクトリノード部
分は、該ディレクトリを記述する情報を包含し、該ディ
レクトリブロック部分は、ディレクトリ内で各ディレク
トリを記述するエントリ及びファイルを包含しており、
該ファイル部分は、ファイルノード部分及びデータ部分
を有し、該ファイルノード部分は、該ファイル及び複数
の実行標識を識別する情報を包含し、各実行標識は、複
数の論理的に連続なロケーションの実行を識別し、該デ
ータ部分は、複数の実行からなることを特徴とするコン
ピュータシステム。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US400533 | 1989-08-29 | ||
| US07/400,533 US5371885A (en) | 1989-08-29 | 1989-08-29 | High performance file system |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2227906A Division JPH03171239A (ja) | 1989-08-29 | 1990-08-29 | 高性能ファイルシステム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JPH08278904A true JPH08278904A (ja) | 1996-10-22 |
Family
ID=23583991
Family Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2227906A Pending JPH03171239A (ja) | 1989-08-29 | 1990-08-29 | 高性能ファイルシステム |
| JP7354961A Pending JPH08278904A (ja) | 1989-08-29 | 1995-11-01 | 高性能ファイルシステム |
Family Applications Before (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2227906A Pending JPH03171239A (ja) | 1989-08-29 | 1990-08-29 | 高性能ファイルシステム |
Country Status (5)
| Country | Link |
|---|---|
| US (3) | US5371885A (ja) |
| EP (1) | EP0416445A3 (ja) |
| JP (2) | JPH03171239A (ja) |
| AU (2) | AU646225B2 (ja) |
| CA (1) | CA2024174C (ja) |
Families Citing this family (216)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH04271443A (ja) * | 1991-02-27 | 1992-09-28 | Canon Inc | データベース構築方法及び装置 |
| US5628014A (en) * | 1992-03-20 | 1997-05-06 | Paranode, Inc. | Methods and apparatus for node caching at the file level |
| US5506983A (en) * | 1992-07-06 | 1996-04-09 | Microsoft Corporation | Method and system for transactioning of modifications to a tree structured file |
| US5539908A (en) * | 1992-11-24 | 1996-07-23 | International Business Machines Corporation | Dynamically linked and shared compression/decompression |
| DE69429378T2 (de) * | 1993-04-01 | 2002-05-23 | Microsoft Corp., Redmond | Gemeinsamer Speicherbereich für lange und kurze Dateinamen |
| US6286013B1 (en) | 1993-04-01 | 2001-09-04 | Microsoft Corporation | Method and system for providing a common name space for long and short file names in an operating system |
| US5572709A (en) * | 1993-06-18 | 1996-11-05 | Lucent Technologies Inc. | Using dynamically-linked libraries to add side effects to operations |
| US5613105A (en) * | 1993-06-30 | 1997-03-18 | Microsoft Corporation | Efficient storage of objects in a file system |
| US5471675A (en) * | 1993-07-27 | 1995-11-28 | Taligent, Inc. | Object oriented video framework system |
| JP3270216B2 (ja) * | 1993-10-08 | 2002-04-02 | 富士通株式会社 | ファイル名検出方式 |
| US5568639A (en) * | 1993-11-24 | 1996-10-22 | Menai Corporation | Method and apparatus for providing an object-oriented file structuring system on a computer |
| US5499358A (en) * | 1993-12-10 | 1996-03-12 | Novell, Inc. | Method for storing a database in extended attributes of a file system |
| US5450579A (en) * | 1994-03-24 | 1995-09-12 | International Business Machines Corporation | Method and apparatus for error recovery in computer peripheral devices |
| US5551020A (en) * | 1994-03-28 | 1996-08-27 | Flextech Systems, Inc. | System for the compacting and logical linking of data blocks in files to optimize available physical storage |
| US5574903A (en) * | 1994-05-13 | 1996-11-12 | Apple Computer, Inc. | Method and apparatus for handling request regarding information stored in a file system |
| US6564321B2 (en) | 1995-04-28 | 2003-05-13 | Bobo Ii Charles R | Systems and methods for storing, delivering, and managing messages |
| US5668970A (en) * | 1994-06-20 | 1997-09-16 | Cd Rom, U.S.A., Inc. | Method and apparatus for generating a file allocation table for a storage medium with no file allocation table using file storage information |
| US5737594A (en) * | 1994-07-05 | 1998-04-07 | Trustus Pty Ltd. | Method for matching elements of two groups |
| JPH0830397A (ja) * | 1994-07-20 | 1996-02-02 | Sony Corp | 情報記憶装置 |
| DE19513308A1 (de) * | 1994-10-04 | 1996-04-11 | Hewlett Packard Co | Dreidimensionales Dateisystem unter Verwendung einer virtuellen Knotenarchitektur |
| US5745752A (en) * | 1994-12-13 | 1998-04-28 | Microsoft Corporation | Dual namespace client having long and short filenames |
| US5617568A (en) * | 1994-12-14 | 1997-04-01 | International Business Machines Corporation | System and method for supporting file attributes on a distributed file system without native support therefor |
| US5579516A (en) * | 1994-12-15 | 1996-11-26 | Hewlett-Packard Company | Method for storing data files on a multiple volume media set |
| JP3464836B2 (ja) * | 1995-01-19 | 2003-11-10 | 富士通株式会社 | 記憶装置のメモリ管理装置 |
| US5675769A (en) * | 1995-02-23 | 1997-10-07 | Powerquest Corporation | Method for manipulating disk partitions |
| US5706472A (en) * | 1995-02-23 | 1998-01-06 | Powerquest Corporation | Method for manipulating disk partitions |
| US5930831A (en) * | 1995-02-23 | 1999-07-27 | Powerquest Corporation | Partition manipulation architecture supporting multiple file systems |
| US6108759A (en) * | 1995-02-23 | 2000-08-22 | Powerquest Corporation | Manipulation of partitions holding advanced file systems |
| US5864856A (en) * | 1995-04-21 | 1999-01-26 | Actuate Software, Inc. | Process and apparatus for simplifying access to information stored in databases |
| US5740469A (en) * | 1995-04-24 | 1998-04-14 | Motorola Inc. | Apparatus for dynamically reading/writing multiple object file formats through use of object code readers/writers interfacing with generalized object file format interface and applications programmers' interface |
| US5715455A (en) * | 1995-05-18 | 1998-02-03 | International Business Machines Corporation | Apparatus and method for storing file allocation table efficiently in memory |
| US5764992A (en) * | 1995-06-06 | 1998-06-09 | Apple Computer, Inc. | Method and apparatus for automatic software replacement |
| US5713017A (en) * | 1995-06-07 | 1998-01-27 | International Business Machines Corporation | Dual counter consistency control for fault tolerant network file servers |
| WO1997003405A2 (en) * | 1995-07-13 | 1997-01-30 | Philips Electronics N.V. | Method and system for data repetition between logically successive clusters |
| US5771379A (en) * | 1995-11-01 | 1998-06-23 | International Business Machines Corporation | File system and method for file system object customization which automatically invokes procedures in response to accessing an inode |
| US6393492B1 (en) | 1995-11-03 | 2002-05-21 | Texas Instruments Incorporated | Method and arrangement for operating a mass memory storage peripheral computer device connected to a host computer |
| US5742817A (en) * | 1995-12-08 | 1998-04-21 | Emc Corporation | Method and apparatus for file server addressing |
| US5754844A (en) * | 1995-12-14 | 1998-05-19 | Sun Microsystems, Inc. | Method and system for accessing chunks of data using matching of an access tab and hashing code to generate a suggested storage location |
| GB2312059B (en) * | 1996-04-12 | 2000-11-15 | Sony Uk Ltd | Data storage |
| US5778430A (en) * | 1996-04-19 | 1998-07-07 | Eccs, Inc. | Method and apparatus for computer disk cache management |
| US6119118A (en) * | 1996-05-10 | 2000-09-12 | Apple Computer, Inc. | Method and system for extending file system metadata |
| US5819298A (en) * | 1996-06-24 | 1998-10-06 | Sun Microsystems, Inc. | File allocation tables with holes |
| US6424991B1 (en) | 1996-07-01 | 2002-07-23 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server communication framework |
| US6266709B1 (en) | 1996-07-01 | 2001-07-24 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server failure reporting process |
| US5848246A (en) * | 1996-07-01 | 1998-12-08 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server session manager in an interprise computing framework system |
| US6434598B1 (en) | 1996-07-01 | 2002-08-13 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server graphical user interface (#9) framework in an interprise computing framework system |
| US6304893B1 (en) | 1996-07-01 | 2001-10-16 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server event driven message framework in an interprise computing framework system |
| US6035396A (en) * | 1996-07-01 | 2000-03-07 | Iomega Corporation | Method for sharing a storage medium between computers having disparate operating systems |
| US6272555B1 (en) | 1996-07-01 | 2001-08-07 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server-centric interprise computing framework system |
| US5987245A (en) * | 1996-07-01 | 1999-11-16 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture (#12) for a client-server state machine framework |
| US5999972A (en) * | 1996-07-01 | 1999-12-07 | Sun Microsystems, Inc. | System, method and article of manufacture for a distributed computer system framework |
| US6038590A (en) * | 1996-07-01 | 2000-03-14 | Sun Microsystems, Inc. | Object-oriented system, method and article of manufacture for a client-server state machine in an interprise computing framework system |
| US5875344A (en) * | 1996-07-16 | 1999-02-23 | Compaq Computer Corporation | Using a file enabler with firmware |
| US5857203A (en) * | 1996-07-29 | 1999-01-05 | International Business Machines Corporation | Method and apparatus for dividing, mapping and storing large digital objects in a client/server library system |
| US5828876A (en) * | 1996-07-31 | 1998-10-27 | Ncr Corporation | File system for a clustered processing system |
| US5727206A (en) * | 1996-07-31 | 1998-03-10 | Ncr Corporation | On-line file system correction within a clustered processing system |
| US5875444A (en) * | 1996-12-10 | 1999-02-23 | International Business Machines Corporation | Computer file system check and repair utility |
| DE69719934T2 (de) * | 1996-12-20 | 2003-11-27 | International Business Machines Corp., Armonk | Verfahren und Vorrichtung zur schnellen und sicheren Datensammlung |
| US5832501A (en) * | 1996-12-31 | 1998-11-03 | Apple Computer, Inc. | Method and system for filtering file manager attribute values |
| DE19708755A1 (de) | 1997-03-04 | 1998-09-17 | Michael Tasler | Flexible Schnittstelle |
| JP3547069B2 (ja) * | 1997-05-22 | 2004-07-28 | 日本電信電話株式会社 | 情報関連づけ装置およびその方法 |
| US5933825A (en) * | 1997-07-21 | 1999-08-03 | Apple Computer, Inc. | Arbitrating concurrent access to file system objects |
| US6298401B1 (en) | 1997-08-11 | 2001-10-02 | Seagate Technology Llc | Object oriented storage device having a disc drive controller providing an interface exposing methods which are invoked to access objects stored in a storage media |
| US6336120B1 (en) * | 1997-08-26 | 2002-01-01 | International Business Machines Corporation | Method and system for supporting hierarchical storage management (HSM) file system across multiple platforms |
| US6321358B1 (en) | 1997-08-28 | 2001-11-20 | Seagate Technology Llc | Object reconstruction on object oriented data storage device |
| US6070254A (en) * | 1997-10-17 | 2000-05-30 | International Business Machines Corporation | Advanced method for checking the integrity of node-based file systems |
| US6065019A (en) * | 1997-10-20 | 2000-05-16 | International Business Machines Corporation | Method and apparatus for allocating and freeing storage utilizing multiple tiers of storage organization |
| US7930278B2 (en) * | 1998-02-13 | 2011-04-19 | Oracle International Corporation | Methods to perform disk writes in a distributed shared disk system needing consistency across failures |
| US7200623B2 (en) | 1998-11-24 | 2007-04-03 | Oracle International Corp. | Methods to perform disk writes in a distributed shared disk system needing consistency across failures |
| US6597688B2 (en) | 1998-06-12 | 2003-07-22 | J2 Global Communications, Inc. | Scalable architecture for transmission of messages over a network |
| US6411770B1 (en) * | 1998-07-02 | 2002-06-25 | Sony Corporation | Data recording method and apparatus |
| US6223262B1 (en) | 1998-08-18 | 2001-04-24 | International Business Machines Corporation | Method for multi-volume, write-behind data storage in a distributed processing system |
| US6216209B1 (en) | 1998-08-18 | 2001-04-10 | International Business Machines Corporation | Multi-volume, write-behind data storage in a distributed processing system |
| US6237068B1 (en) | 1998-08-18 | 2001-05-22 | International Business Machines Corp. | System for multi-volume, write-behind data storage in a distributed processing system |
| US6269377B1 (en) * | 1998-09-21 | 2001-07-31 | Microsoft Corporation | System and method for managing locations of software components via a source list |
| US7058563B1 (en) | 1998-09-23 | 2006-06-06 | Microsoft Corporation | Device driver auto-load |
| US6574588B1 (en) * | 1998-09-23 | 2003-06-03 | Microsoft Corporation | Solid-state memory device that emulates a known storage device |
| GB9822841D0 (en) * | 1998-10-20 | 1998-12-16 | Koninkl Philips Electronics Nv | File systems supporting data sharing |
| US6665779B1 (en) * | 1998-12-24 | 2003-12-16 | Roxio, Inc. | Image backup method for backing up disk partitions of a storage device |
| US7296060B2 (en) * | 1998-12-24 | 2007-11-13 | Intel Corporation | System and method for automatically identifying and attaching related documents |
| US6341325B2 (en) * | 1999-01-12 | 2002-01-22 | International Business Machines Corporation | Method and apparatus for addressing main memory contents including a directory structure in a computer system |
| US6233105B1 (en) * | 1999-03-29 | 2001-05-15 | Inventec Corporation | Method of disk formatting |
| US6374265B1 (en) * | 1999-03-29 | 2002-04-16 | Inventec Corp. | Method for backup and recovery of the long filename in computer system |
| US6401093B1 (en) | 1999-03-31 | 2002-06-04 | International Business Machines Corporation | Cross file system caching and synchronization |
| EP1049029A3 (en) * | 1999-04-28 | 2003-07-09 | Emc Corporation | File systems with versatile indirection |
| US6895418B1 (en) | 1999-04-28 | 2005-05-17 | Emc Corporation | Versatile indirection in an extent based file system |
| JP2001043117A (ja) * | 1999-07-28 | 2001-02-16 | Sharp Corp | ディスク媒体管理方法 |
| US6910054B1 (en) * | 1999-08-16 | 2005-06-21 | International Business Machines Corporation | Methods, systems and computer program products for storing data using a rolling window file |
| US6594675B1 (en) * | 1999-08-26 | 2003-07-15 | International Business Machines Corporation | Method, system for using file name to access application program where a logical file system processes pathname to determine whether the request is a file on storage device or operation for application program |
| US6530038B1 (en) | 1999-09-16 | 2003-03-04 | International Business Machines Corporation | Streamlined initialization and refresh of file system directory limits |
| US6578054B1 (en) | 1999-10-04 | 2003-06-10 | Microsoft Corporation | Method and system for supporting off-line mode of operation and synchronization using resource state information |
| ATE390788T1 (de) | 1999-10-14 | 2008-04-15 | Bluearc Uk Ltd | Vorrichtung und verfahren zur hardware-ausführung oder hardware-beschleunigung von betriebssystemfunktionen |
| US6470345B1 (en) * | 2000-01-04 | 2002-10-22 | International Business Machines Corporation | Replacement of substrings in file/directory pathnames with numeric tokens |
| US6424975B1 (en) | 2000-01-07 | 2002-07-23 | Trg Products, Inc. | FAT file system in palm OS computer |
| US6874062B1 (en) * | 2000-02-22 | 2005-03-29 | Unisys Corporation | System and method for utilizing a hierarchical bitmap structure for locating a set of contiguous ordered search items having a common attribute |
| US6862689B2 (en) | 2001-04-12 | 2005-03-01 | Stratus Technologies Bermuda Ltd. | Method and apparatus for managing session information |
| US6594674B1 (en) * | 2000-06-27 | 2003-07-15 | Microsoft Corporation | System and method for creating multiple files from a single source file |
| US6763428B1 (en) | 2000-08-02 | 2004-07-13 | Symantec Corporation | Methods and systems for performing push-pull optimization of files while file storage allocations are actively changing |
| US6948010B2 (en) | 2000-12-20 | 2005-09-20 | Stratus Technologies Bermuda Ltd. | Method and apparatus for efficiently moving portions of a memory block |
| US6970892B2 (en) * | 2001-02-16 | 2005-11-29 | Stratus Technologies Bermuda Ltd | Implementing standards-based file operations in proprietary operating systems |
| US6766413B2 (en) | 2001-03-01 | 2004-07-20 | Stratus Technologies Bermuda Ltd. | Systems and methods for caching with file-level granularity |
| US6874102B2 (en) | 2001-03-05 | 2005-03-29 | Stratus Technologies Bermuda Ltd. | Coordinated recalibration of high bandwidth memories in a multiprocessor computer |
| CN1147795C (zh) * | 2001-04-29 | 2004-04-28 | 北京瑞星科技股份有限公司 | 检测和清除已知及未知计算机病毒的方法、系统 |
| GB2377049A (en) * | 2001-06-30 | 2002-12-31 | Hewlett Packard Co | Billing for utilisation of a data storage array |
| US7444393B2 (en) * | 2001-10-30 | 2008-10-28 | Keicy K. Chung | Read-only storage device having network interface, a system including the device, and a method of distributing files over a network |
| GB0129044D0 (en) * | 2001-12-05 | 2002-01-23 | Koninkl Philips Electronics Nv | Data storage methods and apparatuses with basic and extended file system capacity |
| US6909910B2 (en) | 2002-02-01 | 2005-06-21 | Microsoft Corporation | Method and system for managing changes to a contact database |
| TW552501B (en) * | 2002-03-22 | 2003-09-11 | Taiwan Semiconductor Mfg | Version recording and tracking method |
| US6895413B2 (en) * | 2002-03-22 | 2005-05-17 | Network Appliance, Inc. | System and method for performing an on-line check of a file system |
| US7058665B1 (en) * | 2002-06-21 | 2006-06-06 | Unisys Corporation | Verification of data coherency in word-addressable files that support concurrent access |
| US6996695B2 (en) * | 2002-07-17 | 2006-02-07 | Masse Wayne P | Method, system, and storage medium for optimizing disk space and information access |
| US6954831B2 (en) * | 2002-08-29 | 2005-10-11 | International Business Machines Corporation | Method, system, and article of manufacture for borrowing physical volumes |
| US6961812B2 (en) * | 2002-10-03 | 2005-11-01 | International Business Machines Corporation | Universal disk format volumes with variable size |
| US8041735B1 (en) | 2002-11-01 | 2011-10-18 | Bluearc Uk Limited | Distributed file system and method |
| US7457822B1 (en) | 2002-11-01 | 2008-11-25 | Bluearc Uk Limited | Apparatus and method for hardware-based file system |
| CN1711606A (zh) * | 2002-11-07 | 2005-12-21 | 皇家飞利浦电子股份有限公司 | 具有主文件系统区域和虚拟文件系统区域的记录载体 |
| US7146371B2 (en) * | 2002-12-05 | 2006-12-05 | International Business Machines Corporation | Performance and memory bandwidth utilization for tree searches using tree fragmentation |
| US7702659B2 (en) * | 2003-03-27 | 2010-04-20 | Sandisk Il Ltd. | Robust, self-maintaining file system |
| US20050192985A1 (en) * | 2003-03-31 | 2005-09-01 | Fujitsu Limited | Apparatus and method for classifying files, and computer product |
| US7607000B1 (en) | 2003-05-13 | 2009-10-20 | Apple Inc. | Method for booting an operating system |
| US7120637B2 (en) * | 2003-05-30 | 2006-10-10 | Microsoft Corporation | Positional access using a b-tree |
| US7069351B2 (en) * | 2003-06-02 | 2006-06-27 | Chung Keicy K | Computer storage device having network interface |
| JP4490917B2 (ja) * | 2003-07-24 | 2010-06-30 | パナソニック株式会社 | ファイル管理方法及び情報処理装置 |
| US7644376B2 (en) | 2003-10-23 | 2010-01-05 | Microsoft Corporation | Flexible architecture for notifying applications of state changes |
| US20050131960A1 (en) * | 2003-12-15 | 2005-06-16 | Reed Benjamin C. | Method and system of accessing at least one target file in a computer system with an operating system with file locking implemented at file-open time |
| US7380246B2 (en) * | 2003-12-15 | 2008-05-27 | Lenovo (Singapore) Pte. Ltd. | Method and system of accessing at least one target file in a computer system with an operating system with file locking implemented with byte-range locking |
| JP4354268B2 (ja) * | 2003-12-22 | 2009-10-28 | 株式会社河合楽器製作所 | 信号処理装置 |
| US7814131B1 (en) | 2004-02-02 | 2010-10-12 | Network Appliance, Inc. | Aliasing of exported paths in a storage system |
| US7428557B2 (en) * | 2004-03-22 | 2008-09-23 | Microsoft Corporation | Efficient data transfer to/from storage medium of computing device |
| JP4227931B2 (ja) * | 2004-04-15 | 2009-02-18 | 株式会社日立製作所 | 情報記憶装置、情報格納方法及び情報記憶処理プログラム |
| US7424574B1 (en) | 2004-04-21 | 2008-09-09 | Sun Microsystems, Inc. | Method and apparatus for dynamic striping |
| US7603568B1 (en) | 2004-04-21 | 2009-10-13 | Sun Microsystems, Inc. | Method and apparatus for self-validating checksums in a file system |
| US7415653B1 (en) | 2004-04-21 | 2008-08-19 | Sun Microsystems, Inc. | Method and apparatus for vectored block-level checksum for file system data integrity |
| US7412450B1 (en) | 2004-05-26 | 2008-08-12 | Sun Microsystems, Inc. | Method and apparatus for identifying tampering of data in a file system |
| US7225314B1 (en) | 2004-05-26 | 2007-05-29 | Sun Microsystems, Inc. | Automatic conversion of all-zero data storage blocks into file holes |
| US7281188B1 (en) | 2004-05-26 | 2007-10-09 | Sun Microsystems, Inc. | Method and system for detecting and correcting data errors using data permutations |
| US7496586B1 (en) | 2004-05-26 | 2009-02-24 | Sun Microsystems, Inc. | Method and apparatus for compressing data in a file system |
| US7526622B1 (en) | 2004-05-26 | 2009-04-28 | Sun Microsystems, Inc. | Method and system for detecting and correcting data errors using checksums and replication |
| GB2415797B (en) * | 2004-06-24 | 2009-02-25 | Symbian Software Ltd | A method for improving the performance of a file system in a computer device |
| US7533225B1 (en) | 2004-08-17 | 2009-05-12 | Sun Microsystems, Inc. | Method and apparatus for enabling adaptive endianness |
| US7437528B1 (en) * | 2004-08-17 | 2008-10-14 | Sun Microsystems, Inc. | Gang blocks |
| US7873782B2 (en) * | 2004-11-05 | 2011-01-18 | Data Robotics, Inc. | Filesystem-aware block storage system, apparatus, and method |
| EP1825372A2 (en) * | 2004-11-05 | 2007-08-29 | Data Robotics Incorporated | Dynamically expandable and contractible fault-tolerant storage system permitting variously sized storage devices and method |
| US7904906B2 (en) * | 2004-11-23 | 2011-03-08 | Stratus Technologies Bermuda Ltd. | Tracking modified pages on a computer system |
| US8606830B2 (en) | 2004-12-17 | 2013-12-10 | Microsoft Corporation | Contiguous file allocation in an extensible file system |
| US8321439B2 (en) | 2004-12-17 | 2012-11-27 | Microsoft Corporation | Quick filename lookup using name hash |
| US7873596B2 (en) * | 2006-05-23 | 2011-01-18 | Microsoft Corporation | Extending cluster allocations in an extensible file system |
| US9639554B2 (en) * | 2004-12-17 | 2017-05-02 | Microsoft Technology Licensing, Llc | Extensible file system |
| CN100449504C (zh) * | 2005-01-05 | 2009-01-07 | 华为技术有限公司 | 一种基于bitmap表的缓存管理方法 |
| JP4722519B2 (ja) * | 2005-03-25 | 2011-07-13 | 株式会社日立製作所 | 計算機システム及びストレージサーバ、検索サーバ、端末装置並びに検索方法 |
| KR100714691B1 (ko) * | 2005-05-04 | 2007-05-04 | 삼성전자주식회사 | 파일 시스템에 추가 정보를 저장하고 관리하는 장치 및방법 |
| US20060253440A1 (en) * | 2005-05-09 | 2006-11-09 | Ibm Confidential | Eliminating file redundancy in a computer filesystem and establishing match permission in a computer filesystem |
| CN100419756C (zh) * | 2005-09-13 | 2008-09-17 | 北京中星微电子有限公司 | 文件分配表文件系统读写方法及装置 |
| US7480684B2 (en) * | 2005-11-04 | 2009-01-20 | Sun Microsystems, Inc. | Method and system for object allocation using fill counts |
| US20070106868A1 (en) * | 2005-11-04 | 2007-05-10 | Sun Microsystems, Inc. | Method and system for latency-directed block allocation |
| US7743225B2 (en) * | 2005-11-04 | 2010-06-22 | Oracle America, Inc. | Ditto blocks |
| US7865673B2 (en) * | 2005-11-04 | 2011-01-04 | Oracle America, Inc. | Multiple replication levels with pooled devices |
| US7873799B2 (en) * | 2005-11-04 | 2011-01-18 | Oracle America, Inc. | Method and system supporting per-file and per-block replication |
| US20070112895A1 (en) * | 2005-11-04 | 2007-05-17 | Sun Microsystems, Inc. | Block-based incremental backup |
| US7925827B2 (en) * | 2005-11-04 | 2011-04-12 | Oracle America, Inc. | Method and system for dirty time logging |
| US8495010B2 (en) * | 2005-11-04 | 2013-07-23 | Oracle America, Inc. | Method and system for adaptive metadata replication |
| US7716519B2 (en) * | 2005-11-04 | 2010-05-11 | Oracle America, Inc. | Method and system for repairing partially damaged blocks |
| US7596739B2 (en) * | 2005-11-04 | 2009-09-29 | Sun Microsystems, Inc. | Method and system for data replication |
| US8549051B2 (en) * | 2005-11-04 | 2013-10-01 | Oracle America, Inc. | Unlimited file system snapshots and clones |
| US7716445B2 (en) * | 2005-11-04 | 2010-05-11 | Oracle America, Inc. | Method and system for storing a sparse file using fill counts |
| US7877554B2 (en) * | 2005-11-04 | 2011-01-25 | Oracle America, Inc. | Method and system for block reallocation |
| US7376758B2 (en) * | 2005-11-04 | 2008-05-20 | Sun Microsystems, Inc. | I/O dependency graphs |
| US7930495B2 (en) * | 2005-11-04 | 2011-04-19 | Oracle America, Inc. | Method and system for dirty time log directed resilvering |
| US8635190B2 (en) * | 2005-11-04 | 2014-01-21 | Oracle America, Inc. | Method and system for pruned resilvering using a dirty time log |
| US8938594B2 (en) * | 2005-11-04 | 2015-01-20 | Oracle America, Inc. | Method and system for metadata-based resilvering |
| US7689877B2 (en) * | 2005-11-04 | 2010-03-30 | Sun Microsystems, Inc. | Method and system using checksums to repair data |
| US7899989B2 (en) * | 2005-11-04 | 2011-03-01 | Oracle America, Inc. | Method and system for using a block allocation policy |
| JP2007141124A (ja) * | 2005-11-22 | 2007-06-07 | Sanyo Electric Co Ltd | リスト作成装置 |
| US7660826B2 (en) * | 2006-05-02 | 2010-02-09 | International Business Machines Corporation | Implementing adaptive buffer management on network fetches of directory contents and object attributes |
| US9971776B1 (en) * | 2006-06-29 | 2018-05-15 | Veritas Technologies Llc | Method and apparatus for extending functionality of an operating system |
| JP5002201B2 (ja) * | 2006-06-30 | 2012-08-15 | 株式会社東芝 | メモリシステム |
| JP4961606B2 (ja) * | 2006-08-29 | 2012-06-27 | アイシン・エィ・ダブリュ株式会社 | データ管理システム、更新用ファイル生成システム、及び、データ更新方法 |
| US7840657B2 (en) * | 2006-10-31 | 2010-11-23 | Oracle America, Inc. | Method and apparatus for power-managing storage devices in a storage pool |
| US7584229B2 (en) * | 2006-10-31 | 2009-09-01 | Sun Microsystems, Inc. | Method and system for priority-based allocation in a storage pool |
| US7783847B2 (en) * | 2006-10-31 | 2010-08-24 | Oracle America Inc. | Method and system for reallocating blocks in a storage pool |
| US9734086B2 (en) | 2006-12-06 | 2017-08-15 | Sandisk Technologies Llc | Apparatus, system, and method for a device shared between multiple independent hosts |
| US7747664B2 (en) * | 2007-01-16 | 2010-06-29 | Microsoft Corporation | Storage system format for transaction safe file system |
| US7792882B2 (en) * | 2007-09-27 | 2010-09-07 | Oracle America, Inc. | Method and system for block allocation for hybrid drives |
| US8769185B2 (en) * | 2007-10-23 | 2014-07-01 | Keicy Chung | Computer storage device having separate read-only space and read-write space, removable media component, system management interface, and network interface |
| US7836226B2 (en) | 2007-12-06 | 2010-11-16 | Fusion-Io, Inc. | Apparatus, system, and method for coordinating storage requests in a multi-processor/multi-thread environment |
| US8176017B2 (en) * | 2007-12-14 | 2012-05-08 | Microsoft Corporation | Live volume access |
| US8073884B2 (en) * | 2007-12-20 | 2011-12-06 | Hewlett-Packard Development Company, L.P. | System and method to derive high level file system information by passively monitoring low level operations on a FAT file system |
| US8095728B2 (en) * | 2008-04-18 | 2012-01-10 | Oracle America, Inc. | Method and system for power aware I/O scheduling |
| US8037279B2 (en) * | 2008-06-12 | 2011-10-11 | Oracle America, Inc. | Method and system for cross-domain data sharing |
| US7921280B2 (en) * | 2008-06-27 | 2011-04-05 | Intel Corporation | Selectively powered retirement unit using a partitioned allocation array and a partitioned writeback array |
| US8135907B2 (en) * | 2008-06-30 | 2012-03-13 | Oracle America, Inc. | Method and system for managing wear-level aware file systems |
| US20100036858A1 (en) * | 2008-08-06 | 2010-02-11 | Microsoft Corporation | Meta file system - transparently managing storage using multiple file systems |
| 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 |
| US8230208B2 (en) * | 2009-04-20 | 2012-07-24 | Intel Corporation | Booting an operating system of a system using a read ahead technique |
| US8280858B2 (en) * | 2009-06-29 | 2012-10-02 | Oracle America, Inc. | Storage pool scrubbing with concurrent snapshots |
| JP5310399B2 (ja) * | 2009-09-01 | 2013-10-09 | 富士通株式会社 | 索引管理装置の処理方法および索引管理装置 |
| US8510334B2 (en) | 2009-11-05 | 2013-08-13 | Oracle International Corporation | Lock manager on disk |
| US8433865B2 (en) | 2009-12-11 | 2013-04-30 | Microsoft Corporation | Consistency without ordering dependency |
| US8793440B2 (en) | 2010-06-17 | 2014-07-29 | Microsoft Corporation | Error detection for files |
| US8897432B2 (en) | 2010-07-01 | 2014-11-25 | Etherfax, Llc | System and method of remote fax interconnect technology |
| US8713067B1 (en) * | 2010-07-09 | 2014-04-29 | Open Invention Network, Llc | Stable file system |
| CN102479163A (zh) * | 2010-11-25 | 2012-05-30 | 鸿富锦精密工业（深圳）有限公司 | 多硬盘自动识别系统及方法 |
| US8776094B2 (en) | 2011-08-11 | 2014-07-08 | Microsoft Corporation | Runtime system |
| US8249230B1 (en) | 2012-01-09 | 2012-08-21 | EC Data Systems, Inc. | Scalable and flexible internet fax architecture |
| US8254538B1 (en) | 2012-02-27 | 2012-08-28 | EC Data Systems, Inc. | Scalable and flexible internet fax architecture for processing outbound fax messages |
| US9542401B1 (en) | 2012-03-30 | 2017-01-10 | EMC IP Holding Company LLC | Using extents of indirect blocks for file mapping of large files |
| US9223791B2 (en) | 2013-07-02 | 2015-12-29 | Red Hat, Inc. | System and method for reading file blocks |
| US9558297B1 (en) * | 2014-03-27 | 2017-01-31 | EMC IP Holding Company LLC | Memory management techniques |
| US10277778B2 (en) | 2014-06-24 | 2019-04-30 | Ec Data Systems Inc. | Audit logging for a secure, scalable and flexible internet fax architecture |
| US20170083630A1 (en) * | 2015-09-21 | 2017-03-23 | Egemen Tas | Method to virtualize large files in a sandbox |
| US10635504B2 (en) | 2014-10-16 | 2020-04-28 | Microsoft Technology Licensing, Llc | API versioning independent of product releases |
| US10614044B2 (en) * | 2016-07-07 | 2020-04-07 | Tuxera, Inc. | Systems and methods for performing data object renaming operations |
| US10733144B2 (en) * | 2016-07-13 | 2020-08-04 | Netapp, Inc. | Persistent indexing and free space management for flat directory |
| US11855971B2 (en) * | 2018-01-11 | 2023-12-26 | Visa International Service Association | Offline authorization of interactions and controlled tasks |
| EP3736705B1 (en) * | 2018-02-05 | 2024-09-18 | Huawei Technologies Co., Ltd. | Date query method and device |
| CN111124256B (zh) * | 2018-10-31 | 2023-10-27 | 伊姆西Ip控股有限责任公司 | 管理存储的方法、设备和计算机程序产品 |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS63116232A (ja) * | 1986-10-30 | 1988-05-20 | アプル・コンピユータ・インコーポレーテツド | 階層構造のファイルシステムおよびそれを構成する方法 |
| JPS63187344A (ja) * | 1987-01-30 | 1988-08-02 | Nec Corp | フアイル内空き領域管理方式 |
Family Cites Families (18)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4435752A (en) * | 1973-11-07 | 1984-03-06 | Texas Instruments Incorporated | Allocation of rotating memory device storage locations |
| US4156908A (en) * | 1974-02-28 | 1979-05-29 | Burroughs Corporation | Cursive mechanism in a data driven digital data processor |
| US4454576A (en) * | 1981-05-18 | 1984-06-12 | International Business Machines Corporation | Report preparation |
| US4468728A (en) * | 1981-06-25 | 1984-08-28 | At&T Bell Laboratories | Data structure and search method for a data base management system |
| US4464653A (en) * | 1981-12-09 | 1984-08-07 | The Bendix Corporation | Combustible gas detection system |
| CA1233266A (en) * | 1985-02-21 | 1988-02-23 | William L. Terrell | Configuration capability for devices in an open system |
| US4825354A (en) * | 1985-11-12 | 1989-04-25 | American Telephone And Telegraph Company, At&T Bell Laboratories | Method of file access in a distributed processing computer network |
| US5047918A (en) * | 1985-12-31 | 1991-09-10 | Tektronix, Inc. | File management system |
| US4709367A (en) * | 1986-03-31 | 1987-11-24 | International Business Machines Corporation | Method and apparatus for distinguishing between diskettes in a diskette drive |
| US5034914A (en) * | 1986-05-15 | 1991-07-23 | Aquidneck Systems International, Inc. | Optical disk data storage method and apparatus with buffered interface |
| US4945475A (en) * | 1986-10-30 | 1990-07-31 | Apple Computer, Inc. | Hierarchical file system to provide cataloging and retrieval of data |
| US5008820A (en) * | 1987-03-30 | 1991-04-16 | International Business Machines Corporation | Method of rapidly opening disk files identified by path names |
| JPH01128266A (ja) * | 1987-11-13 | 1989-05-19 | Pioneer Electron Corp | 書込み可能型ディスク用ドライブ装置の制御方法 |
| US4953080A (en) * | 1988-04-25 | 1990-08-28 | Hewlett-Packard Company | Object management facility for maintaining data in a computer system |
| US5014208A (en) * | 1989-01-23 | 1991-05-07 | Siemens Corporate Research, Inc. | Workcell controller employing entity-server model for physical objects and logical abstractions |
| US5398142B1 (en) * | 1989-05-31 | 1997-09-16 | Raxco Inc | Method for eliminating file fragmentation and reducing average seek times in a magnetic disk media environment |
| US5274802A (en) * | 1991-02-22 | 1993-12-28 | Gte Mobilnet Incorporated | Method for restoring lost databases by comparing existing database and generic database, and generating cellular switch commands to update the generic database |
| CA2122098C (en) * | 1993-04-27 | 1999-02-02 | Michael John Camille Marsh | Printing apparatus |
-
1989
- 1989-08-29 US US07/400,533 patent/US5371885A/en not_active Expired - Lifetime
-
1990
- 1990-08-28 EP EP19900116474 patent/EP0416445A3/en not_active Withdrawn
- 1990-08-28 CA CA002024174A patent/CA2024174C/en not_active Expired - Lifetime
- 1990-08-29 JP JP2227906A patent/JPH03171239A/ja active Pending
- 1990-08-29 AU AU61912/90A patent/AU646225B2/en not_active Expired
-
1994
- 1994-05-16 AU AU63093/94A patent/AU676284B2/en not_active Expired
- 1994-09-01 US US08/299,542 patent/US5608901A/en not_active Expired - Lifetime
- 1994-09-01 US US08/299,511 patent/US5873118A/en not_active Expired - Lifetime
-
1995
- 1995-11-01 JP JP7354961A patent/JPH08278904A/ja active Pending
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPS63116232A (ja) * | 1986-10-30 | 1988-05-20 | アプル・コンピユータ・インコーポレーテツド | 階層構造のファイルシステムおよびそれを構成する方法 |
| JPS63187344A (ja) * | 1987-01-30 | 1988-08-02 | Nec Corp | フアイル内空き領域管理方式 |
Also Published As
| Publication number | Publication date |
|---|---|
| AU6191290A (en) | 1991-03-07 |
| EP0416445A3 (en) | 1992-10-28 |
| US5371885A (en) | 1994-12-06 |
| AU6309394A (en) | 1994-07-14 |
| EP0416445A2 (en) | 1991-03-13 |
| US5873118A (en) | 1999-02-16 |
| US5608901A (en) | 1997-03-04 |
| CA2024174A1 (en) | 1991-03-01 |
| JPH03171239A (ja) | 1991-07-24 |
| CA2024174C (en) | 1996-05-21 |
| AU646225B2 (en) | 1994-02-17 |
| AU676284B2 (en) | 1997-03-06 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JPH08278904A (ja) | 高性能ファイルシステム | |
| EP0415346B1 (en) | Method and system for dynamic volume tracking in an installable file system | |
| US6792518B2 (en) | Data storage system having mata bit maps for indicating whether data blocks are invalid in snapshot copies | |
| US7363540B2 (en) | Transaction-safe FAT file system improvements | |
| US8914567B2 (en) | Storage management system for virtual machines | |
| US6934822B2 (en) | Organization of multiple snapshot copies in a data storage system | |
| US6957362B2 (en) | Instantaneous restoration of a production copy from a snapshot copy in a data storage system | |
| US8156165B2 (en) | Transaction-safe FAT files system | |
| US6185575B1 (en) | In-place disk partition canonization and storage optimization | |
| US5826012A (en) | Boot-time anti-virus and maintenance facility | |
| US7225210B2 (en) | Block level data snapshot system and method | |
| US20150378921A1 (en) | Systems and methods for storage service automation | |
| KR100317691B1 (ko) | 로그 구조화 목표 저장장치를 사전에 구성하여 볼륨을 효율적으로 복사하는 방법 및 장치 | |
| US20070180206A1 (en) | Method of updating a duplicate copy of an operating system on the same disk | |
| JPH04504018A (ja) | 消去不可能な記憶媒体上にファイルを読出しかつ書込む方法 | |
| JPS62165249A (ja) | ペ−ジ・セグメント化仮想記憶デ−タ処理システムにおけるセグメント・サイズを自動的に大きくする方法 | |
| US6996682B1 (en) | System and method for cascading data updates through a virtual copy hierarchy | |
| CN114911574B (zh) | 一种数据处理方法及装置 | |
| US10235373B2 (en) | Hash-based file system | |
| US7191297B2 (en) | Method for volume manager to have configurable device type and subtype for application use | |
| Kwon | Designing Systems for Emerging Memory Technologies |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 19971027 |