System and method for generating extensible file system metadata
42 claims: 8 independent, 34 dependent
- 1データを格納するためのストレージ空間を提供するように構成されたストレージデバイスと、そして 前記ストレージデバイスにより提供された前記ストレージ空間を複数のファイルを含むファイルシステムコンテンツに編成するように、そして前記ストレージデバイスへのアクセスを管理するように、構成されたファイルシステムとを含むシステムであって、 前記ファイルシステムが、 ファイルシステムコンテンツアクセスイベントを検出し、前記ファイルシステムコンテンツアクセスイベントの検出に応答して、前記ファイルシステムコンテンツアクセスイベントを指示するメタデータレコードを生成し、かつ前記ストレージデバイス上の前記ファイルシステムコンテンツ内に前記メタデータレコードを格納するように更に構成され、 前記ファイルシステムは拡張可能な自己記述データフォーマットにしたがって前記メタデータレコードを生成するように更に構成され、 前記メタデータレコード内に含まれる個々のデータエレメントは1つまたは複数の対応のタグフィールドにより範囲が定められ、前記メタデータレコード内に含まれる所与の個々のデータエレメントに対して前記1つまたは複数の対応のタグフィールドが前記所与の個々のデータエレメントの情報のタイプを指示することを特徴とするシステム。
- 2前記ファイルシステムコンテンツアクセスイベントの検出はバンド内で実行され、前記バンド内での検出は前記検出ファイルシステムコンテンツアクセスイベントの発生と同期していることを特徴とする請求項1に記載のシステム。
- 3前記拡張可能な自己記述データフォーマットは、あるバージョンの拡張可能なマーク付け言語(XML)フォーマットに準拠することを特徴とする請求項1に記載のシステム。
- 4前記メタデータレコードは、所与のファイルに対応する名前付きストリームに格納されることを特徴とする請求項1に記載のシステム。
- 5前記メタデータレコードは、前記ファイルシステムに対応するイベントログに格納されることを特徴とする請求項1に記載のシステム。
- 6前記ファイルシステムコンテンツは、前記複数のファイルの1つ又はそれ以上に格納された1つ又はそれ以上のメタデータレコードとファイルデータを含むことを特徴とする請求項1に記載のシステム。
- 7コンテンツプロセッサとアプリケーションを更に含み、前記コンテンツプロセッサは、前記ファイルシステムコンテンツアクセスイベントのバンド外での検出に応答して、前記アプリケーションを呼び出すように構成され、前記バンド外での検出は前記ファイルシステムコンテンツアクセスイベントが既に実行されてしまった後で発生することを特徴とする請求項1に記載のシステム。
- 8問合せエンジンを更に含み、これによってアプリケーションが前記ファイルシステムコンテンツを問い合わせることを特徴とする請求項1に記載のシステム。
- 9ファイルシステムが前記ストレージデバイスにより提供された前記ストレージ空間を複数のファイルを含むファイルシステムコンテンツに編成するステップと、 前記ファイルシステムがファイルシステムコンテンツアクセスイベントを検出するステップと、 前記ファイルシステムコンテンツアクセスイベントの検出に応答して、前記ファイルシステムが、前記ファイルシステムコンテンツアクセスイベントを指示するメタデータレコードを生成し、かつ前記ストレージデバイス上の前記ファイルシステムコンテンツ内に前記メタデータレコードを格納するステップと、そして 前記ファイルシステムが拡張可能な自己記述データフォーマットにしたがって前記メタデータレコードを記憶するステップであって、前記メタデータレコード内に含まれる個々のデータエレメントは1つまたは複数の対応のタグフィールドにより範囲が定められ、前記メタデータレコード内に含まれる所与の個々のデータエレメントに対して前記1つまたは複数の対応のタグフィールドが前記所与の個々のデータエレメントの情報のタイプを指示するステップとを含む方法。
- 10前記ファイルシステムコンテンツアクセスイベントの検出はバンド内で実行され、前記バンド内での検出は前記検出ファイルシステムコンテンツアクセスイベントの発生と同期していることを特徴とする請求項9に記載の方法。
- 11前記拡張可能な自己記述データフォーマットは、拡張可能なマーク付け言語(XML)フォーマットに準拠することを特徴とする請求項9に記載の方法。
- 12前記メタデータレコードは、所与のファイルに対応する名前付きストリームに格納されることを特徴とする請求項9に記載の方法。
- 13前記メタデータレコードは、イベントログに格納されることを特徴とする請求項9に記載の方法。
- 14前記ファイルシステムコンテンツは、複数のファイルの1つ又はそれ以上に格納された1つ又はそれ以上のメタデータレコードとファイルデータを含むことを特徴とする請求項9に記載の方法。
- 15前記ファイルシステムコンテンツアクセスイベントのバンド外での検出に応答してアプリケーションを呼び出すステップであって、前記バンド外での検出は前記ファイルシステムコンテンツアクセスイベントが既に実行されてしまった後で発生する、ステップを更に含むことを特徴とする請求項9に記載の方法。
- 16前記ファイルシステムコンテンツを問い合わせる段階を更に含むことを特徴とする請求項9に記載の方法。
- 17プログラム命令を 記録した コンピュータアクセス可能 な記録 媒体であって、前記プログラム命令は、 ファイルシステムが前記ストレージデバイスにより提供された前記ストレージ空間を複数のファイルを含むファイルシステムコンテンツに編成するステップと、 前記ファイルシステムがファイルシステムコンテンツアクセスイベントを検出するステップと、 前記ファイルシステムコンテンツアクセスイベントの検出に応答して、前記ファイルシステムが、前記ファイルシステムコンテンツアクセスイベントを指示するメタデータレコードを生成し、かつ前記ストレージデバイス上の前記ファイルシステムコンテンツ内に前記メタデータレコードを格納するステップと、そして 前記ファイルシステムが拡張可能な自己記述データフォーマットにしたがって前記メタデータレコードを記憶するステップであって、前記メタデータレコード内に含まれる個々のデータエレメントは1つまたは複数の対応のタグフィールドにより範囲が定められ、前記メタデータレコード内に含まれる所与の個々のデータエレメントに対して前記1つまたは複数の対応のタグフィールドが前記所与の個々のデータエレメントの情報のタイプを指示するステップとを含む方法をコンピュータに実行させることを特徴とするコンピュータアクセス可能 な記録 媒体。
- 18前記ファイルシステムコンテンツアクセスイベントの検出はバンド内で実行され、前記バンド内での検出は前記検出ファイルシステムコンテンツアクセスイベントの発生と同期していることを特徴とする請求項17に記載のコンピュータアクセス可能 な記録 媒体。
- 19前記拡張可能な自己記述データフォーマットは、拡張可能なマーク付け言語(XML)フォーマットに準拠することを特徴とする請求項17に記載のコンピュータアクセス可能 な記録 媒体。
- 20前記メタデータレコードは、所与のファイルに対応する名前付きストリームに格納されることを特徴とする請求項17に記載のコンピュータアクセス可能 な記録 媒体。
- 21前記メタデータレコードは、イベントログに格納されることを特徴とする請求項17に記載のコンピュータアクセス可能 な記録 媒体。
- 22前記ファイルシステムコンテンツは、複数のファイルの1つ又はそれ以上に格納された1つ又はそれ以上のメタデータレコードとファイルデータを含むことを特徴とする請求項17に記載のコンピュータアクセス可能 な記録 媒体。
- 23前記プログラム命令は前記ファイルシステムコンテンツアクセスイベントのバンド外での検出に応答してアプリケーションを呼び出すように更に実行可能であり、前記バンド外での検出は前記ファイルシステムコンテンツアクセスイベントが既に実行されてしまった後で発生する、請求項17に記載のコンピュータアクセス可能 な記録 媒体。
- 24前記プログラム命令は、前記ファイルシステムコンテンツを問い合わせるために更に実行可能であることを特徴とする請求項17に記載のコンピュータアクセス可能 な記録 媒体。
- 25データを記憶するためのストレージ空間を提供するように構成されたストレージデバイスと、そして 前記ストレージデバイスにより提供された前記ストレージ空間を複数のファイルを含むファイルシステムコンテンツに編成するように、そして前記ストレージデバイスへのアクセスを管理し、ファイルシステムコンテンツを格納し、前記ファイルシステムとは異なるアプリケーションにより生成されたファイルシステムコンテンツアクセスイベントのバンド内検出を実行し、更にこれに応答して前記ファイルシステムコンテンツアクセスイベントを指示するそれぞれのイベントレコードを生成し、そして前記ファイルシステムコンテンツ内に前記それぞれのイベントレコードを記憶するように構成されたファイルシステムと、そして 前記イベントレコードのバンド外検出を実行し、これに応答して追加のファイルシステムコンテンツを生成するように構成された前記アプリケーションとは異なるコンテンツプロセッサとを含むシステムであって、 前記バンド内での検出は前記検出ファイルシステムコンテンツアクセスイベントの発生と同期し、 前記バンド外での検出は前記ファイルシステムコンテンツアクセスイベントが既に実行されてしまった後で発生し、 前記アプリケーションの少なくともサブセットのメンバーは相互にまたは前記コンテンツプロセッサと直接に相互作用しないように構成され、そして 前記コンテンツプロセッサは、前記イベントレコードの少なくともいくつかの前記バンド外での検出に依拠し、前記アプリケーションの前記少なくともサブセットの2つ以上のオペレーションに更に依拠し、かつ前記ファイルシステムコンテンツに更に依拠する前記トランザクションを実行するように更に構成されている、ことを特徴とするシステム。
- 26前記トランザクションを実行するために、前記コンテンツプロセッサは、前記イベントレコードの少なくとも1つのバンド外検出の実行に応答して前記アプリケーションの少なくとも1つを呼び出すように更に構成され、前記バンド外検出は前記イベントレコードが生成されてしまった後で発生することを特徴とする請求項25に記載のシステム。
- 27前記コンテンツプロセッサは、前記ファイルシステムコンテンツアクセスイベントを問合せシステムに通知するように更に構成され、これに応答して前記問合せシステムは、前記ファイルシステムコンテンツアクセスイベントに対して前記ファイルシステムコンテンツのインデックスの参照一貫性を維持するように構成されていることを特徴とする請求項25に記載のシステム。
- 281つ又はそれ以上の前記メタデータレコードは、所与のファイルに対応する名前付きストリームに格納されることを特徴とする請求項25に記載のシステム。
- 29前記メタデータレコードは、拡張可能な自己記述データフォーマットで格納されることを特徴とする請求項25に記載のシステム。
- 30前記拡張可能な自己記述データフォーマットは、拡張可能なマーク付け言語(XML)フォーマットに準拠することを特徴とする請求項29に記載のシステム。
- 31ファイルシステムが前記ストレージデバイスにより提供された前記ストレージ空間を複数のファイルを含むファイルシステムコンテンツに編成するステップと、 前記ファイルシステムが、前記ファイルシステムとは異なるアプリケーションにより生成されたファイルシステムコンテンツアクセスイベントのバンド内検出を実行するステップであって、前記バンド内での検出は前記検出ファイルシステムコンテンツアクセスイベントの発生と同期しているステップと、 前記バンド内検出に応答して、前記ファイルシステムが前記ファイルシステムコンテンツアクセスイベントを指示するそれぞれのイベントレコードを生成し、前記ファイルシステムコンテンツ内に前記それぞれのイベントレコードを記憶するステップと、 前記アプリケーションとは異なるコンテンツプロセッサが前記イベントレコードのバンド外検出を実行するステップであって、前記アプリケーションの少なくともサブセットのメンバーは相互にまたは前記コンテンツプロセッサと直接に相互作用しないように構成され、そして前記コンテンツプロセッサによる前記バンド外検出は前記ファイルシステムコンテンツアクセスイベントが既に実行されてしまった後で発生するステップと、そして 前記コンテンツプロセッサは、前記イベントレコードの少なくともいくつかの前記バンド外での検出に依拠し、前記アプリケーションの前記少なくともサブセットの2つ以上のオペレーションに更に依拠し、かつ前記ファイルシステムコンテンツに更に依拠する前記トランザクションを実行するステップとを含む方法。
- 32前記コンテンツプロセッサが前記イベントレコードの少なくとも1つのバンド外検出の実行に応答して前記アプリケーションの少なくとも1つを呼び出すステップを更に含むことを特徴とする請求項31に記載の方法。
- 33前記コンテンツプロセッサが前記ファイルシステムコンテンツアクセスイベントの所与の1つを問合せシステムに通知するステップを更に含み、これに応答して前記問合せシステムは、前記所与のファイルシステムコンテンツアクセスイベントに対して前記ファイルシステムコンテンツのインデックスの参照一貫性を維持するように構成されていることを特徴とする請求項31に記載の方法。
- 341つ又はそれ以上の前記メタデータレコードは、所与のファイルに対応する名前付きストリームに格納されることを特徴とする請求項31に記載の方法。
- 35前記メタデータレコードは、拡張可能な自己記述データフォーマットで格納されることを特徴とする請求項31に記載の方法。
- 36前記拡張可能な自己記述データフォーマットは、拡張可能なマーク付け言語(XML)フォーマットに準拠することを特徴とする請求項35に記載の方法。
- 37プログラム命令を 記録した コンピュータアクセス可能 な記録 媒体であって、前記プログラム命令は、 ファイルシステムが前記ストレージデバイスにより提供された前記ストレージ空間を複数のファイルを含むファイルシステムコンテンツに編成するステップと、 前記ファイルシステムが、前記ファイルシステムとは異なるアプリケーションにより生成されたファイルシステムコンテンツアクセスイベントをバンド内での検出を実行するステップであって、前記バンド内での検出は前記検出ファイルシステムコンテンツアクセスイベントの発生と同期しているステップと、 前記ファイルシステムコンテンツアクセスイベントの検出に応答して、前記ファイルシステムが、前記ファイルシステムコンテンツアクセスイベントを指示するそれぞれのイベントレコードを生成し、かつ前記ファイルシステムコンテンツ内に前記それぞれのイベントレコードを格納するステップと、そして 前記アプリケーションとは異なるコンテンツプロセッサが前記イベントレコードのバンド外検出を実行するステップであって、前記アプリケーションの少なくともサブセットのメンバーは相互にまたは前記コンテンツプロセッサと直接に相互作用しないように構成され、そして前記コンテンツプロセッサによる前記バンド外検出は前記ファイルシステムコンテンツアクセスイベントが既に実行されてしまった後で発生するステップと、そして 前記コンテンツプロセッサは、前記イベントレコードの少なくともいくつかの前記バンド外での検出に依拠し、前記アプリケーションの前記少なくともサブセットの2つ以上のオペレーションに更に依拠し、かつ前記ファイルシステムコンテンツに更に依拠する前記トランザクションを実行するステップとを含む方法をコンピュータに実行させることを特徴するコンピュータアクセス可能 な記録 媒体。
- 38前記プログラム命令は、前記イベントレコードのバンド外検出の実行に応答して前記アプリケーションの少なくとも1つを呼び出すステップを前記コンテンツプロセッサに実行させることが更に可能であることを特徴とする請求項37に記載のコンピュータアクセス可能 な記録 媒体。
- 39前記プログラム命令は、所与の1つのファイルシステムコンテンツアクセスイベントを問合せシステムに通知するステップを前記コンテンツプロセッサに実行させることが更に可能であり、これに応答して前記問合せシステムは、前記所与のファイルシステムコンテンツアクセスイベントに対して前記ファイルシステムコンテンツのインデックスの参照一貫性を維持するように構成されていることを特徴とする請求項37に記載のコンピュータアクセス可能 な記録 媒体。
- 401つ又はそれ以上の前記メタデータレコードは、所与のファイルに対応する名前付きストリームに格納されることを特徴とする請求項37に記載のコンピュータアクセス可能 な記録 媒体。
- 41前記メタデータレコードは、拡張可能な自己記述データフォーマットで格納されることを特徴とする請求項37に記載のコンピュータアクセス可能 な記録 媒体。
- 42前記拡張可能な自己記述データフォーマットは、拡張可能なマーク付け言語(XML)フォーマットに準拠することを特徴とする請求項41に記載のコンピュータアクセス可能 な記録 媒体。
Independent claims42
94 paragraphs, as filed
The present invention relates to a computer system, and more specifically to a file-based storage system.
Computer systems often process large amounts of information, including application data and executable code configured to process such data. In many embodiments, the computer system provides various types of high capacity storage devices such as magnetic and optical disk drives, tape drives, etc. that are configured to store data. In order to provide a systematic canonical interface for accessing these stored data, such storage devices are frequently organized into a hierarchy of files by software such as the operating system. Files often define the minimum level of data granularity that a user can interact with within a storage device, but various applications and operating system processes have a lower level of granularity than the entire file to the data in the file. Can be operated against.
In some file-based computer systems, various types of information about a file, also called metadata, are stored in addition to the file itself. However, in a typical traditional computer system, metadata support is limited to a small number of fixed types of file attributes and cannot be augmented when additional file information is required. Moreover, the procedure for accessing metadata may be limited to identifying a given file and then searching for its associated metadata, rather than a more flexible procedure.
<p> In addition, a complex computer environment provides a large number of applications, each of which interacts with a file or storage device to perform a particular function. In some cases, each of several applications is configured to perform a particular step in a complex multi-step transaction. However, such applications may limit interaction or coordination functions and require significant intervention on the part of the system user to coordinate transaction processing.</p>
<p> Various embodiments of systems and methods for generating extensible file system metadata are disclosed. In one embodiment, the system includes a storage device configured to store data and a file system configured to manage access to the storage device and store file system content. The file system is further configured to detect a file system content access event and generate a metadata record in response to the detection of the file system content access event, the metadata record being extensible self-describing data. Stored in format.</p><p> In one particular implementation of the system, detecting file system content access events is performed within the band as described in more detail below. In another particular implementation of the system, the extensible self-describing data format can conform to one version of the extensible marking language (XML) format.</p><p> In one embodiment, it stores file system content, detects file system content access events, generates metadata records in response to detection of file system content access events, and metadata in an extensible self-describing data format. Methods involving storing records are also contemplated.</p>
Although various modifications and alternatives are possible in the present invention, specific embodiments of the present invention will be illustrated in the drawings as examples and will be described in detail herein. However, the drawings and detailed description herein are not intended to limit the invention to the particular embodiments disclosed, and all modifications contained within the spirit and scope of the invention as defined by the appended claims. It should be understood that it protects forms, equivalents, and alternative forms.
(Overview of computer system) Here, with reference to FIG. 1, a block diagram of one embodiment of a computer system is shown. In the illustrated embodiment, the system 10 includes a plurality of host devices 20a, 20b coupled to the plurality of storage devices 30a, 30b via the system interconnect 40. Further, the host device 20b includes a system memory 25 in the illustrated embodiment. For the sake of brevity, the elements indicated herein by the letters following the reference number may be referred to generically by reference number alone. For example, the host devices 20a and 20b and the storage devices 30a and 30b may be collectively referred to as the host device 20 and the storage device 30.
In various embodiments of the system 10, the host device 20 is configured to access data stored in one or more of the storage devices 30. In one embodiment, the system 10 is implemented within a single computer system, eg, as an integrated storage server. In such an embodiment, for example, the host device 20 can be an individual processor, the system memory 25 can be a cache memory such as static RAM (SRAM), and the storage device 30 can be a hard disk. It can be a high capacity storage device such as a drive or other writable or rewritable medium, and the system interconnect 40 includes a peripheral bus interconnect such as a peripheral component interface (PCI) bus. In some such embodiments, the system interconnect 40 includes several types of interconnects between the host device 20 and the storage device 30. For example, the system interconnect 40 couples one or more processor buses (not shown) configured to be coupled to the host device 20, and the processor buses to one or more peripheral buses. Includes one or more bus bridges (not shown) configured as such, and one or more storage device interfaces (not shown) configured to couple peripheral buses to the storage device 30. Types of storage device interfaces include, for example, small computer system interfaces (SCSI), ATA packet interfaces (ATAPI), firewires, and / or universal serial buses (USB) in various embodiments, but other interface types. Many other embodiments are possible and contemplated, including.
In an embodiment of system 10 implemented within a single computer system, system 10 is such that it provides most of the data storage requirements for one or more other computer systems (not shown). It is configured to communicate with such other computer systems. In another embodiment, the system 10 is configured as a distributed storage system, such as a storage area network (SAN). In such an embodiment, for example, the host device 20 can be an individual computer system such as a server system, and the system memory 25 is composed of one or more types of dynamic RAM (DRAM). The storage device 30 can be a stand-alone storage node, each containing one or more hard disk drives or other types of storage, and the system interconnect 40 is Ethernet® (registered). Trademark)) or Fiber It can be a communication network such as Channel (Fiber Channel). The distributed storage configuration of system 10 can facilitate the scaling of storage system capacity and data bandwidth between the host and the storage device.
In yet another embodiment, the system 10 is configured as a hybrid storage system, where some storage devices 30 are integrated into the same computer system as some host devices 20, and other storage devices 30 are It is configured as a stand-alone device coupled to another host device 20 over the network. In such a hybrid storage system, the system interconnection 40 includes various interconnect mechanisms such as the peripheral buses and network interconnections described above.
Note that two host devices 20 and two storage devices 30 are shown in FIG. 1, but system 10 may have any number of each of these types of devices in another embodiment. I want to be. Also, in some embodiments of system 10, more than one instance of system memory 25 can be used, for example, in another host device 20 or storage device 30. Further, in some embodiments, the given system memory 25 can reside outside the host device 20 or storage device 30, and is directly coupled to or systematically attached to the given host device 20 or storage device 30. It can be indirectly coupled via the interconnect 40.
In many embodiments of system 10, one or more host devices 20 are configured to execute program instructions to reference data, thereby performing computational functions. In some embodiments, the system memory 25 can be one embodiment of a computer-accessible medium configured to store such program instructions and data. However, in other embodiments, program instructions and / or data can be received, sent, or stored on another type of computer-accessible medium. Generally speaking, the computer accessible medium includes a storage medium or a memory medium such as a magnetic or optical medium (eg, disk or CD-ROM) included in the system 10 as the storage device 30. The computer-accessible medium also includes RAM (eg, SDRAM, DDR) as system memory 25 in some embodiments of system 10. Includes volatile or non-volatile media such as SDRAM, RDRAM, SRAM, etc.), ROM, etc. Further, a computer-accessible medium is such as an electronic, electromagnetic, or digital signal transmitted via a communication medium such as a network and / or wireless link, which is included in some embodiments of the system 10 as a system interconnect 40. Includes transmission medium or signal.
In some embodiments, the program instructions and data stored in a computer-accessible medium as described above implement an operating system that can provide an environment for executing various application programs. For example, a given host device 20 is configured to run some version of the Microsoft Windows® operating system, Unix® / Linux operating system, Apple Macintosh operating system, or another suitable operating system. Will be done. In addition, a given host device may execute application programs such as word processors, web browsers and / or servers, email clients and / or servers, multimedia applications, etc., among many other available applications. It is composed.
While running on a given host device 20, either the operating system or a given application makes a request for data that is loaded from or stored in a given storage device 30. Can be generated. For example, the code corresponding to a part of the operating system or the application itself can be stored in a given storage device 30, thus responding to a required operating system routine or application program call with the corresponding code. Can be searched and executed. Similarly, the execution of an operating system or application can create data to be stored.
In some embodiments, the movement and processing of data stored in the storage device 30 can be managed by a software-based storage system. One such embodiment is shown in Figure 2 for content aware storage. shows application layer 100 interfaced to multiple storage devices 230A-C via system) 150. Some modules shown in Figure 2 are configured to run in user run mode or "user space", others are configured to run in kernel run mode or "kernel space". .. In the illustrated embodiment, application layer 100 includes multiple user space software processes 112A-C. Each process interfaces to the storage system 150 through multiple application programming interfaces (APIs) 114A-C so that each of the processes 112 accesses each of the APIs 114A-C. The storage system 150 is a kernel space storage management system 200 indicating an interface to application layer 100 via API 114A; a user space content processing system 300 indicating an interface to application layer 100 via API 114B; application layer 100 via API 114C. Includes a user space query system 400 that shows an interface to. In the illustrated embodiment, the storage management system 200 further interfaces with the storage device 230A-C.
In some embodiments, any number of processes 112 and / or storage devices 230 can be implemented. In some embodiments, all or part of the content processing system 300 and / or the query system 400 can be implemented in kernel space, and in some embodiments a process configured to run in kernel space. Is configured to access the storage system 150 via API 114 or other APIs specific to kernel space processes.
In one embodiment, each of the processes 112 can accommodate a given user application, and each is configured to access the storage device 230A-C via a call to API 114. API 114 allows process 112 to access various components of storage system 150. For example, in one embodiment the API 114 may include a function call indicated by the storage system 150 that a given process 112 may call, and in another embodiment the API 114 may include other types of interprocess communication. Can be supported. In one embodiment, the storage device 230 can be an example of the storage device 30 of FIG. Further, in one embodiment, any of the components of the storage system 150 and / or any of the processes 112 are with program instructions stored in a computer accessible medium such as the system memory 25 of FIG. The data is configured to run on one or more of the host devices 20 in Figure 1.
The storage system 150 is configured to provide various storage-related services, as will be described in more detail below along with the description of FIGS. 3-9. For example, in one embodiment, the storage management system 200 is configured to use a file system to organize the data stored by the storage device 230, and the various processes 112 store the data as hierarchical files. Can be operated. Further, the storage system 150 is configured to monitor the operation of access and / or operation to the stored data and generate a record of such operation. The query system 400 is configured to provide process 112 with an interface for querying data stored by storage device 230 and querying records of operations that access such data. Finally, the content processing system 300 is configured to monitor the activity of the storage management system 200 and generate additional records of such activity. As described in more detail below, the content processing system 300 is further configured to call one or more applications in response to detection of such activity, thereby providing application layer 100 activity. Provides a mechanism for initiating content processing activity based on the activity of the storage management system 200, rather than directly (eg, based on a data request by process 112). In some embodiments of the storage system 150, the content processing system 300, the query system 400, or both systems can be omitted while maintaining the services provided by the storage management system 200. It is planned.
(Storage management system and file system) As mentioned above, in some embodiments, the storage management system 200 can provide a data structure and a control structure for organizing the storage space provided by the storage device 230 into files. In various embodiments, the data structure is described in more detail below, such as information such as the identity of each file, its location within the storage device 230 (eg, mapping to a particular physical location within a particular storage device). Includes one or more tables configured to store other information about each file as such. Also in various embodiments, the control structure includes executable routines for manipulating the file, such as changing the file identity or calling a function to modify the file content. Collectively, these data and control structures are referred to herein as file systems, and the particular data formats and protocols implemented by a given file system are referred to herein as file system formats. is there.
In some embodiments, the file system can be integrated into the operating system so that access to any of the data stored on the storage device 230 is controlled by file system control and data structures. Different operating systems can implement different unique file systems using different formats, but in some embodiments a given operating system has a file system format specific to another operating system. Includes file systems that support several different types of file system formats, including. In such embodiments, the various file system formats supported by the file system can be referred to herein as local file systems. Further, in some embodiments, the file system can be implemented using a multi-layer feature arranged hierarchically as shown in FIG.
FIG. 3 shows one embodiment of the storage management system 200. In the illustrated embodiment, the storage management system includes a file system 205 configured to interface with one or more device drivers 224, which device driver is configured to interface with the storage device 230. As illustrated within the storage system 150 of FIG. 2, the components of the storage management system 200 are configured to run in kernel space, but in some embodiments, they are part of the storage management system 200. The components of are also intended to be configured to run within user space. Similarly, in one embodiment, any of the components of the storage management system 200, such as program instructions and data stored in a computer-accessible medium, such as the system memory 25 of FIG. It is configured to run on one or more of the host devices 20.
As mentioned above with respect to system 10 in FIG. 1, a given host device 20 can reside in a different computer system than a given storage device 30 and can access the storage device over the network. Similarly, with respect to the storage management system 200, in one embodiment, a given process, such as process 112A, can be run remotely and access the storage device 230 over the network. In the illustrated embodiment, file system 205 includes network protocol 225 to support access to the file system by remote processes. In some embodiments, the network protocol 225 includes, for example, support for a network file system (NFS) protocol or a common internet file system (CIFS) protocol, but any suitable network protocol may be used. Such protocols can be supported in some embodiments.
File system 205 is configured to support multiple local file systems. In the illustrated embodiment, the file system 205 includes a VERITAS (VxFS) format local file system 240A, a Berkeley high speed file system (FFS) format local file system 240B, and a proprietary (X) format local file system 240X. However, in other embodiments, any number of local file file system formats or combinations thereof can be supported by the file system 205. To provide a common interface to various local file systems 240, file system 205 includes virtual file system 222. In one embodiment, the virtual file system 222 is configured to translate the file system operations generated by process 112 into a format applicable to the particular local file system 240 targeted by each operation. Further, in the illustrated embodiment, the storage management system 200 includes a device driver 224 that allows the local file system 240 to access the storage device 230. Device driver 224 implements a data transfer protocol specific to the type of interface used by storage device 230. For example, in one embodiment the device driver 224 can support the transfer of data across SCSI and ATAPI interfaces, while in other embodiments the device driver 224 has other types and combinations of interfaces. Can be supported.
In the illustrated embodiment, the file system 205 also includes a filter driver 221. In some embodiments, the filter driver 221 monitors each operation input to file system 205, detects a particular type of operation, and then performs additional operations or modifies the behavior of the detected operations. It is configured to do. For example, in one embodiment, the filter driver 221 is configured to integrate multiple write operations into a single write operation to improve file system performance. In another embodiment, the filter driver 221 is configured to calculate the file signature after detecting a write to the file. In yet another embodiment, the filter driver 221 detects some type of operation on these files, followed by information such as records associated with a particular file, as described in more detail below. Is configured to memorize. In some embodiments, the filter driver 221 is configured to implement one or more combinations of the above-mentioned operations, including other filter operations not specifically mentioned.
It can be said that an embodiment of filter driver 221 configured to detect a file system operation when it is requested or processed performs "in-band" detection of such operation. Alternatively, it can be said that such detection is synchronized with the occurrence of the detected operation or event. In some embodiments, the processing action taken in response to the in-band detection of the operation can affect how the operation is terminated. For example, in-band detection of a file read operation can result in cancellation of the operation if the source of the operation is not granted sufficient privileges to access the requested file. In some embodiments, in-band detection of the operation has no effect on the termination of the operation itself, but records the occurrence of the operation detected in the metadata record as described below. You can generate additional operations like this.
Conversely, a file system operation or event may be detected after this occurrence, so that detection may occur after the operation or event has already ended. Such detection can be said to be "out of band" or asynchronous to the detected operation or event. For example, user process 112 can periodically check the file for the length of the file. The file length can be changed at any time since the last check by user process 112, but the check can be out of band for operations that have changed the file length. In some cases, out-of-band detection may fail to detect some events. With reference to the above example, the file length can be changed several times since the last check by user process 112, but only the last change may be detected.
It should be noted that operations or events can be detected within the band, but actions taken in response to such detections can occur either before or after the end of the detected operation. With reference to the above example, in one embodiment, each operation for modifying the length of the checked file can be detected and recorded within the band. User process 112 is configured to periodically inspect records for the length of the file. Since the length correction operations were detected and recorded within the band, the user process 112 can take into account each of these operations and still perform well after these operations have occurred.
Note that filter driver 221 is part of file system 205, not an application or process in user space. Therefore, the filter driver 221 is configured to operate independently of the applications and processes in the user space 210. Alternatively, or in addition to the above, the filter driver 221 is configured to perform an operation in response to a request received from an application or process within the user space 210.
It should be further noted that in some embodiments, the kernel space 220 includes a process (not shown) that generates access to the storage device 230 similar to the user space process 112. In such an embodiment, the process running in kernel space 220 is configured to access file system 205 via the kernel mode API (not shown) in a manner similar to user space process 112. Thus, in some embodiments, all access to the storage device 230 can be handled by the file system 205 regardless of the type or space of the process that causes the access operation.
Numerous other embodiments of the storage management system 200 and the file system 205 are possible and contemplated. For example, file system 205 can support various numbers and formats of local file system 240, or only a single local file system 240. In some embodiments, the network protocol 225 may be omitted or integrated into a portion of the external storage management system 200 of the file system 205. Similarly, in some embodiments, the virtual file system 222 can be omitted or disabled, for example if only a single local file system 240 is in use. Further, in some embodiments, the filter driver 221 is implemented in different layers of file system 205. For example, in one embodiment the filter driver 221 can be integrated into the virtual file system 222, and in another embodiment an instance of the filter driver 221 can be implemented in each of the local file systems 240.
Files and metadata As described above, the file system 205 is configured to manage access to a plurality of files stored in the storage device 230. In many embodiments, each stored file can have an associated identity used by the file system to distinguish each file from other files. In one embodiment of file system 205, the identity of the file can be a filename, including a string such as "filename.txt". However, in embodiments of the file system 205 that implements a file hierarchy, such as a folder or directory hierarchy, all or part of the file hierarchy can be included in the file identity. For example, the given file name "file1.txt" can exist in the directory "smith" which exists in the directory "users". The directory "users" can exist in the directory "test1", which is the top-level or root-level directory in file system 205 . In some embodiments, file system 205 can define a single "root directory" to include all root level directories if the high level directories do not contain root directories. In other embodiments, multiple top-level directories can coexist such that the high-level directories do not contain any top-level directories. The name of the particular folder or directory in which a given file is located can be referred to herein as the path or pathname of a given file.
In some embodiments of file system 205 that implement a file hierarchy, the identity of a given file is specified by listing each directory in the file path and filename. With reference to the example given above, the identity of a given instance of the filename "file1.txt" can be specified as "/test1/users/smith/file1.txt". In some embodiments of file system 205, the filename alone may not be sufficient to uniquely identify a given file, and a fully specified file identity, including path information, is given. Note that it can be sufficient to uniquely identify the file. For example, there can be a file identified as "/test2/users/smith/file1.txt" that shares the same filename as the above file but is clearly distinguishable by its path. Note that alternative methods of representing a given file identity using path and filename information are possible and conceived. For example, the directory / folder name and the file name can be separated by using various characters, or the directory / folder name and the file name may be specified in a different order.
The file managed by the file system 205 stores application data or program information, which can be collectively referred to as file data, in any of several encoding formats. For example, a given file stores plain text in ASCII coded format, or data in a proprietary application format such as a particular word processor or spreadsheet coded format. In addition, a given file stores video or audio data or executable program instructions in binary format. It is envisioned that many other types of data and encoding formats, as well as combinations of data and encoding formats, will be used in files as file data.
In addition to managing access to the storage device, the various files stored on the storage device, and the file data of the files as described above, in some embodiments, the file system 205 is one or more. It is configured to store the information corresponding to the above given file. The information can be referred to herein as metadata. Generally speaking, metadata contains any type of information associated with a file. In various embodiments, the metadata includes (but not limited to) information such as file identity, size, ownership, and file permissions. Metadata also includes free-form or user-defined data such as records corresponding to file system operations, as described in more detail below. In some embodiments, the information contained in the metadata is predefined (ie, hard-coded) in the file system 205 as, for example, a collection of metadata types defined by the vendor or integrator of the file system 205. In another embodiment, file system 205 is configured to generate a new type of metadata definition during operation. In yet another embodiment, one or more application processes 112 outside of file system 205 are new metadata managed by file system 205, eg, via an instance of API 114 defined for that purpose. Is defined. A combination of such techniques that define metadata is available in several embodiments. Although defined, metadata corresponding to a file and data content of a file can be collectively referred to as file system content in the present specification.
FIG. 4 shows one embodiment of a file system configured to store files and associated metadata. The embodiment of file system 205 shown in FIG. 4 includes the elements shown in the embodiment of FIG. 3, but some of these elements are not shown for simplicity. In the illustrated embodiment, the file system 205 is in the filter driver 221 and in each named stream 260a-n, directory 255 associated with each of any number of files 250a-n, directory 255, file 250a-n. Includes each associated named stream 260 and event log 270. One generic instance of file 250a-n or named stream 260a-n can be referred to as file 250 or named stream 260, respectively, and file 250a-n and named stream 260a-n are collectively files, respectively. Note that it can be called 250 and named stream 260. As mentioned above, the file 250 and the named stream 260 can be collectively referred to as file system content. In some embodiments, directory 255 can also be included in the file system content.
File 250 can represent a file managed by file system 205 and is configured in various embodiments to store different types of data and program instructions as described above. In a hierarchical implementation of file system 205, one or more files 250 can be included in directory 255 (also called folders). In various embodiments, any number of directories 255 can be provided, some of which are configured to include other directories 255 and files 250 hierarchically. In the illustrated embodiment, each of the file 250 and the directory 255 has a corresponding named stream 260. Each of the named streams 260 is configured to store the metadata associated with its corresponding file. The file 250, directory 255, and named stream 260 are physically stored on one or more storage devices, such as the storage device 230 in FIG. However, for illustration purposes, file 250, directory 255, and named stream 260 are conceptually shown to reside within file system 205. Also, in some embodiments, it is intended that directory 255 be similar to file 250 in terms of metadata generation, and in such embodiments, reference to file 250 in the following description is a directory. Please understand that it can also be applied to 255.
In some embodiments, the filter driver 221 is configured to access the file data stored in a given file 250. For example, the filter driver 221 is configured to detect read and / or write operations received by file system 205 and in response to file data from a given file 250 corresponding to the received operations. It can be read or written to the given file. In some embodiments, the filter driver 221 is configured to generate in-band metadata corresponding to a given file 250 and store the generated metadata in the corresponding named stream 260. For example, upon detecting a file write operation directed to a given file 250, the filter driver 221 updates this metadata in the named stream 260 with the metadata corresponding to the last modification time of the given file 250. It is configured to store updated metadata. Also, in some embodiments, the filter driver 221 may be configured to search for metadata corresponding to a specified file on behalf of a particular application.
Metadata is generated in response to various types of file system activity initiated by process 112 in Figure 2. In some embodiments, the generated metadata includes records of arbitrary complexity. For example, in one embodiment, the filter driver 221 is configured to detect various types of file operation operations such as file creation, deletion, renaming, and / or copy operations, as well as file read and write operations. In some embodiments, such an operation is detected within the band as described above. After detecting a particular file operation, filter driver 221 is configured to generate a record of the operation and store that record in a named stream 260 that is appropriate as metadata for the file 250 targeted by the operation. File.
More generally, any operation that accesses any aspect of file system content, such as reading or writing file data or metadata, can be referred to as a file system content access event. In one embodiment, the filter driver 221 is configured to generate metadata records in response to detection of file system content access events. In some embodiments, the access event targeting metadata itself produces additional metadata. As described in more detail below, in the illustrated embodiment, the event log 270, regardless of whether additional metadata is stored within a particular named stream 260 in response to event detection. It is configured to store a record of detected file system content access events.
Stored metadata records are found in various embodiments, for example, file 250 and / or file permissions such as the identity of the process that generates the operation, the file identity, the file type, the file size, the file owner, and / or the file permissions. Contains various information about the operation. In one embodiment, the record contains a file signature indicating the contents of file 250. The file signature can be a hash type function of all or part of the file content, and has the property that slight differences in the file content result in quantitatively distinct file signatures. For example, the file signature can use the Message Digest 5 (MD5) algorithm, which can generate a signature for another file that differs in file content by only a single bit, but what is the appropriate signature generation algorithm? It is intended that may be used. Records also contain additional information that is not specifically listed.
In one embodiment, a metadata record stored by the filter driver 221 following the detection of a particular file operation is generated and stored in a format that includes the data field with a tag that describes the importance of the associated data field. .. Such a format can be referred to as a "self-describing" data format. For example, a data element in a metadata record has a general syntax: <descriptive_tag> data element </ descriptive_tag> Can be separated by such tag fields with. Here, the "descriptvie_tag" delimiter can describe some aspect of the "data element" field, which serves to compose various data elements in the metadata record. In various embodiments, the self-describing data format can use any of a variety of syntaxes, including various provisions for distinguishing tags from data elements.
The self-describing data format is also extensible in some embodiments. That is, the data format is extended to include additional structural elements as needed. For example, a non-extensible format specifies a fixed structure that a data element must follow, such as a tabular row and column data format or a format with a fixed number and type of tag fields. Conversely, in one embodiment, the extensible self-describing data format takes into account any number of arbitrarily defined tag fields used to separate and compose data. In another embodiment, the extensible self-describing data format allows modifications to the syntax used to specify a given data element. In some embodiments, the extensible self-describing data format is extensible by the user or application while the data is being generated or used.
In one embodiment, either the extensible Marking Language (XML) format, or any data format that conforms to any version of XML, is used as an extensible self-describing format for storing metadata records. Although possible, in other embodiments it is contemplated that any suitable format may be used, including formats that are not extensible or self-describing. XML-formatted records allow arbitrary definition of record fields according to the required metadata recorded. An example of an XML format record is: <record sequence = "1"> <path> /test1/foo.pdf </ path> <type> applciation / pdr </ type> <user id = 1598> username </ user> <group id = 119> groupname </ group> <perm> rw-r--r-- </ perm> <md5> d41d8cd98f00b204e9800998ecf8427e </ md5> <size> 0 </ size> </ record> Such records are attached, for example, to a named stream (eg named stream 260a) associated with a file (eg file 250a) having the file identity "/test1/foo.pdf" following a file creation operation. In this case, the number associated with the "record sequence" field indicates that this record is the first record associated with file 250a. The "path" field contains the file identity, and the "type" field can be provided by the process of issuing the file creation operation in one embodiment, for example extension of the filename or in-file in another embodiment. Indicates the file type to be judged from the header information of. The "user id" field records both the numeric user ID and the letter username of the user associated with the process that initiates the file creation operation, and is a "group". The id field records both the numeric group ID of the user and the character group name. The "perm" field records the file permissions associated with file 250a in a format specific to file system 205 and / or operating system. The "md5" field records the MD5 signature corresponding to the file content, and the "size" field records the length of the file 250a in bytes. In another embodiment, the filter driver 221 is intended to store a record corresponding to a detected operation when the record contains several fields and fields with various definitions and contents. In some embodiments, the filter driver 221 has been read from a given file 250 in the XML format so that it can return XML data regardless of the file data format on which the read operation to the file is based. Can contain data. Similarly, in some embodiments, the filter driver 221 is configured to receive XML format data to be written to a given file 250. In such an embodiment, the filter driver 221 is configured to remove XML formatting before writing the file data to a given file 250.
Note that in some embodiments, the metadata is stored in a structure that is not a named stream. For example, in one embodiment, the metadata corresponding to one or more files is stored in another file in database format or another format. It is also contemplated that in some embodiments, other software modules or components of file system 205 are configured to generate, store, and / or retrieve metadata. For example, the metadata function of filter driver 221 is incorporated into another software module or duplicated by that module.
In the illustrated embodiment, file system 205 includes event log 270. Event log 270 is a named stream similar to named stream 260, but can be associated directly with file system 205 rather than with a specific file. In some embodiments, the file system 205 may include only one event log 270, and in other embodiments it may have more than one event log 270. For example, in one embodiment of file system 205 including a plurality of local file systems 240 as shown in FIG. 2, one history stream can be provided for each local file system 240.
In some embodiments, the filter driver 221 is configured to store metadata records in the event log 270 in response to file system operations or event detection. For example, a read or write operation directed to a particular file 250 can be detected, followed by the filter driver 221 storing a record indicating the operation in the event log 270. In some embodiments, the filter driver 221 is configured to store the metadata record in the event log 270, regardless of whether the corresponding metadata record is also stored in the named stream 260. .. In some embodiments, the event log 270 serves as a centralized history of all detected operations and events occurring within file system 205.
Similar to the records stored in the named stream 260, the records stored by the filter driver 221 in the event log 270 are, in one embodiment, extensible, such as in an extensible marking language (XML) format. Although generated in a self-describing data format, it is also contemplated that in other embodiments any suitable format can be used. As an example, create and modify a given file 250a named "/test1/foo.pdf" and then rename it to file 250b "/test1/destination.pdf" during the operation of file system 205. .. In one embodiment, the event log 270 contains a record of the following example following the rename operation. <recrod> <op> create </ op> <path> /test1/foo.pdf </ path> </ record> <record> <op> modify </ op> <path> test1 / foo.pdf </ path> </ record> <recrod> <op> rename </ op> <path> /test1/destination.pdf <path> <oldpath> /test1/foo.pdf <oldpath> </ record> In this example, the "op" field of each record indicates the operation performed, and the "path" field indicates the file identity of file 250a performed there. For a file rename operation, the "path" field indicates the file identity of the destination file 250b of the rename operation, and the "old path" field indicates the file identity of the source file 250a. In another embodiment, the filter driver 221 stores a record in the event log 270 that includes some fields and fields with various destinations and contents.
The above description of metadata generation is further shown in its entirety in the flowchart shown in FIG. With reference to FIGS. 1 to 5 together, an operation in which file system content such as file data or metadata is stored begins at block 500. In one embodiment, the file system content includes both file data and metadata. Following the storage of file system content, a file system content access event is detected (block 502). In one embodiment, the file system content access event is detected in the band by, for example, the filter driver 221 as described above. In some embodiments, the initial storage of file system content is a file system content access event that is self-detectable. For example, the file creation operation is a file system content access event that can be detected in step 502.
A metadata record is generated in response to the detection of a file system content access event (block 504). You can collect various metadata elements related to operations to access a given file, such as file identity, file ownership, identity of the process that generates the access event, and so on.
Following the generation of the metadata record, the metadata record is stored in an extensible self-describing data format (block 506). In one embodiment, the data format conforms to a version of the XML format. In various embodiments, the metadata record is stored in a named stream associated with a given file, such as one of the named streams 260, or in an event log, such as event log 270.
Content processing system As described, in some embodiments, the storage system is configured to generate in-band metadata in response to various detected file system operations or events. Such operations or events may occur as a result of the execution of various application processes. For example, in any of the various ways (such as start, end, read, write, copy, rename, or any other type of file activity) that a given application produces the corresponding metadata record. You will be able to work with files. In such an embodiment, the resulting metadata record allows systematic tracking of file system activity generated by a given application or process, such tracking performed to any degree of specificity. Can be transparent to the application.
In some cases, many applications interact with the storage system 150 as part of a complex heterogeneous data processing system. For example, companies use database applications to manage inventory and production, accounting applications to track invoices and receipts, finance applications to create quarterly reports, and personnel applications to identify personnel details. .. Additional or different applications can be provided in different embodiments.
Some of these applications can be versions of the same application (eg, accounting and finance use common or related applications), or tightly coupled applications, i.e., communicate directly and collaborate. By sharing a common API, you can almost notice each other's existence and data. For example, when processing an invoice, the accounting application directly notifies the finance application to update the budget. Other applications can be provided by different vendors and may only be loosely coupled, i.e. other applications share a common data format, but are limited to directly communicating and coordinating with each other's operations. Has the function that was done. For example, a financial application may be able to import salary and allowance information generated by a human resources application in response to user intervention, but without such intervention it would not be possible to directly request and receive such information. Can not. Finally, in some cases, some applications shall be completely incompatible, unable to share or interact directly with the data.
Some conglomerate operations can involve several applications, but not just one, all of which may not necessarily be tightly coupled to each other. Such operations, which can be referred to as transactions, include a series of operations undertaken by one or more applications in response to a particular order or a particular event. A set of operations, including a transaction, can also be referred to as a process or procedure performed by a transaction and is arbitrarily defined according to the capabilities of the various applications available.
The status of a transaction is not apparent from the activity of a single-configuration application, and conversely a transaction is a function of the activity of all related applications obtained with information about the process that defines the transaction. For example, depending on the procedure defined by a given company, processing a purchase order involves several steps. First, enter the purchase order via a dedicated application or email interface. Once entered, the requester's identity and privileges are verified, for example by using a human resources application to verify that the requester is an employee with the appropriate signature privileges. It then obtains financial approval, including using a financial application, and verifies that the request is within the budget of the individual or organization requesting the order. Depending on the outcome of these various steps and the complexity of the corporate policy, additional validation such as management approval can be obtained. Once all the requirements are met, the order can be submitted to the vendor and the purchase order transaction process ends.
Any application that supports compound transactions and works will generate activity within the storage system 150 when the file system content is manipulated. File system content containing file data and / or metadata records corresponding to the activity is created in response to the activity as described above. However, as mentioned above, in some cases the progress of a given transaction through its defined process is not apparent from the activity of a given application as reflected in the file system content corresponding to that activity. Sometimes. For example, a human resources application can reflect personal data, but not budget data. Therefore, by querying the Human Resources application, it is possible to verify that a given individual has the appropriate signature privileges for a particular purchase, and the results of that query can be shown in the file system content. However, the HR application cannot determine if there is sufficient budget for the purchase. In fact, in some cases some application, such as a human resources application, may generally be unaware of the extensive transactional content of its operation. That is, an application may not be able to identify whether a given query is part of the process of a given transaction that may span multiple applications.
It can be difficult or impractical to configure each application that can optionally participate in a given transaction that can interact directly with other applications. For example, if the functionality of one or more applications is fixed by an external manufacturer, it may not be possible to perform such a configuration. In the embodiment shown in FIG. 2, the storage system 150 includes a content processing system 300, which in various embodiments monitors file system content stored by the storage management system 200. It is configured to generate additional metadata based on such monitoring and to call the application in response to such monitoring. In some embodiments, the content processing system 300 is configured to coordinate or monitor complex transactions that are unnoticed by its constituent applications.
One embodiment of the content processing system 300 is shown in FIG. In the illustrated embodiment, the content processing system 300 is shown with the embodiment of the file system 205 shown in FIG. The content processing system 300 includes a content processing daemon 320 configured to interact with a plurality of content type specific processors 330a-c, which may also be referred to simply as the content processor 330. The content processing daemon 320 is configured to interact with file 250 on file system 205, named stream 260, and event log 270. Further, the content processing daemon 320 is configured to interact with a query system such as the query system 400 in the embodiment of the storage system 150 including such a query system.
In the illustrated embodiment, the content processing daemon 320 is configured to perform out-of-band detection of operations and events detected and recorded within the band by the filter driver 221. For example, the content processing daemon 320 can scan the event log 270 in some cases to determine that a file system content access event has occurred since the last scan. In response to the detected event, the content processing daemon 320 generates additional file system content as described in more detail below. In some embodiments, the content processing daemon 320 can directly scan the file 250 and / or the named stream 260, and in other embodiments the content processing daemon 320 uses the event log 270 to record events. It is intended that these files 250 and named streams 260 corresponding to are accessible. Further, in some embodiments, the content processing system 300 does not use the event log 270 but includes a unique log of events updated in response to notifications by the filter driver 221.
The content processing daemon 320 interacts with the file system 205 to generate or modify file system content, including file data and metadata, on behalf of one or more content processors 330. In one embodiment, the content processor 330 includes a procedural code or logic configured to monitor a defined process for a particular transaction. For example, a given content processor 330 implements an algorithm or state machine that describes a set of operations defined as part of a particular transaction. Content processor 330 includes identifying information about transaction-related file system content, such as specific file 250 that can be accessed in the middle of a transaction. Further, the content processor 330 contains information for identifying a specific application corresponding to various operations. For example, if a given transaction involves a step performed by an accounting application, the corresponding content processor 330 will have the meta generated by the filter driver 221 of the given file 250 when that file is accessed by the accounting application. Includes a particular application that identifies information, such as an application name or identification code, contained in a data record.
In some embodiments, a given content processor 330 is configured to process all instances of a particular transaction. For example, a content processor 330 configured to monitor the purchase order transactions described above is configured to process all purchase order transactions in progress at a given time. In such an embodiment, a given content processor 330 includes a data structure, whereby individual transactions are identified within the processor, such as by a time stamp or a unique identifier. In another embodiment, each content processor 330 corresponds to a single instance of a given transaction. For example, if a new transaction is detected, a new instance of the content processor 330 will be created from an existing instance (such as a template) or from the content processing daemon 320. In some embodiments, the content processor 330 and the content processing daemon 320 are implemented as a single processing entity, such as a single software module.
The operation of a given content processor 330 can be determined by an algorithm implemented with file system content access event information received via the content processing daemon 320. In one embodiment, the content processor 330 is first inactive or idle until triggered by a particular file system content access event. For example, in a system where a purchase order is initiated by emailing a purchase order to a particular email account, filter driver 221 appends the received purchase order content to the file associated with that particular email account. In response, it creates a metadata record in the event log 270. Subsequently, the content processing daemon 320 detects the record and transmits the instruction of the record to the purchase order content processor 330 which is started in response to the record. In another embodiment, individual instances of the content processor 330 are spawned by the content processor daemon 320 in response to detection of the appropriate launch event.
In one embodiment, the content processor 330 is a passive monitor that functions to detect when a given sequence of events occurs, or when a given state of file system content occurs. For example, content processor 330 executes a series of events, such as approval process steps, in the proper order by examining the metadata records generated by filter driver 221 in response to application activity undertaken during the process. It is configured to detect whether or not it has been used. In another case, the content processor 330 is configured to determine if the file system content is properly formed according to a particular syntax or schema. For example, the content processor 330 can examine the metadata record or file data following the update to determine if it is syntactically correct and properly configured (ie, the required data exists). ..
In another embodiment, the content processor 330 is configured to actively modify the file system content and / or call other applications in response to detection of various events or states of the content. For example, in a document publishing environment, a given document can be in several different formats (eg, Portable Document Format (PDF), HTML Format, Microsoft). Can be used by users in Word format). In such an embodiment, the content processor 330 is configured to automate the generation of the required version of a given document. For example, content processor 330 detects when the master version of a document in a given file 250 is updated by detecting the metadata record of updates to that file in the named stream 260 and / or event log 270. Configured to detect. Upon detecting an update, the content processor 330 can call the appropriate generator or translator application to convert the updated master version into each of the required formats. Such conversions can be made transparently to the user or application updating the master document.
As another example, the content processor 330 is configured to actively perform complex transactions such as the purchase approval process described above. In such cases, the content processor 330 is configured to call various applications as specified in the procedure corresponding to the transaction. For example, the content processor 330 is configured to detect that a new purchase order request has been received via email as described above. The content processor 330 then accesses the file 250, which stores the request data, to extract information from the request, such as the requester's identity and the amount of dollars in the request. Using the extracted information, the content processor 330 interacts with various applications to obtain approval as described above. For example, the content processor 330 generates a query to verify signature privileges in a human resources application, budget status in a financial application, and so on. When user intervention is required, the content processor 330 is configured to generate a prompt that is communicated to the user for a response, eg, via email.
In various embodiments, the content processor 330 is configured to produce output in various formats. In one embodiment, the content processor 330 produces an out-of-band metadata record in response to its processing. For example, a content processor 330 configured to perform schema validation of structured data on a given file 250 produces a metadata record that shows the status of checks in the corresponding named stream 260. In other embodiments, the content processor 330 is configured to generate or modify file data in place of or in addition to the metadata. For example, the schema verification software described above should correct some defects detected while verifying structured data, such as by truncating malformed records or filling in missing data fields. It is composed. As another example, the content processor 330 is configured to interact with the query engine to maintain reference consistency of the data indexed by the query engine, as described in more detail below. In yet another embodiment, the content processor 330 is configured to interact with the application or user. For example, as described above, the content processor 330 is configured to call the application's API in response to detection of a particular event, such as a document content update. In one embodiment, one or more content processors 330 will generate metadata records in an extensible self-describing data format as described above, including formats that conform to any version of the XML format. It is intended to be composed.
The content processing system 300 and its various components can interact with the application, which is process 112 within the application layer 100 as described above, and the content processing system 300 and its various components are different from the application. Please note that. In general, a particular application is unaware of the activity of other applications and cannot access the metadata generated during the operation of file system 205. However, in the illustrated embodiment, the content processing system 300 can access such metadata so that such access detects transaction events that are not fully presented by the operation of a particular application. It is composed of.
FIG. 7 shows one embodiment of the method of operation of the storage system 150 including the content processing system 300. Referring collectively to FIGS. 1 to 4, 6 and 7, the operation begins at block 700, where file system content such as file data or metadata is stored. In one embodiment, the file system content includes both file data and metadata. Following the storage of file system content, a file system content access event is detected within the band (block 702). For example, the file system content access event is detected in the band by the filter driver 221 as described above. As mentioned above, in some embodiments, the initial storage of file system content is a file system content access event that can detect itself. For example, the file creation operation is a file system content access event that can be detected in step 702.
An event record is generated in response to the detection of a file system content access event (block 704). For example, in one embodiment, the filter driver 221 is configured to generate an event record containing information about a file system content access event, such as the type of event and the file system content accessed by it. In one embodiment, such records are stored in event log 270. In some embodiments, it also generates a metadata record that contains additional information about the file system content access event. For example, in one embodiment, the filter driver 221 contains various metadata elements related to operations to access a given file, such as file identity, file ownership, identity of the process that generates the access event, and so on. Configured to collect. In one embodiment, the event record and / or any additional metadata record generated in response to event detection is stored in an extensible self-describing data format, such as XML format, as described above.
After the event record is generated, the event record is detected out of band (block 706). For example, in one embodiment, the content processing daemon 320 or content processor 330 is configured to scan the event log 270 to find event records. In some embodiments, detection of event records includes detection of transactions involving several applications. For example, a particular content processor 330 detects that a given event record indicates a particular type of first step or contiguous step in a transaction with activity in some of some applications.
Additional file system content is generated in response to out-of-band event record detection (block 708). In one embodiment, the additional file system content generated is file data stored in one or more files 250, or metadata records stored in one or more named streams 260. Or both are included. In one embodiment, the application can be additionally called in response to out-of-band event record detection. For example, a given content processor 330 can call an application in the middle of processing a transaction as described above.
(Inquiry about file system contents) As mentioned above, in some embodiments, the file system 205 is configured to store various types of file system content. File system 205 can store many types of file data in one or more files and stores metadata of any complexity corresponding to a given file. File system 205 is configured to consume file system content. For example, file system 205 can implement specific storage policies, which assign files with some usage characteristics as shown in their metadata to specific types of storage. In one embodiment, for example, files that have been used most recently or that have been accessed by some type of process can be assigned to faster storage types, while others can be assigned to slower storage. Can be done.
In some embodiments, an application or operating system process outside of file system 205 (such as process 112 in FIG. 2) is configured to consume file system content. For example, a programmer who writes an application software module may want to create and manipulate specific files and related file data to store or retrieve application data. In addition, such programmers may perform actions that depend on the metadata characteristics of some files, such as configuring the backup program to select only files that have been modified since the last backup time. You may want it. In some embodiments, specific file system content is specified by querying the fill system content to identify content that meets certain criteria. The available criteria for querying file system content depends on the format in which the file system content is stored. For example, in one embodiment, the file system content is stored in a fixed, non-extensible format, such as a tabular data structure, where the description of the data item is not from the self-describing format tag, but from the row and column definitions. .. In such embodiments, the criteria by which file system content can be selected can be determined by the defined structure of the format, such as the definitions of available rows and columns. In embodiments where the file system content is stored in an extensible self-describing format such as the XML format described above, the criteria available for selecting the required file system content is any of the self-describing features of the content. Including.
In the embodiment of the storage system 150 shown in FIG. 2, the query system 400 is configured to provide various processes 112 with a file system content query function via API 114C. One detailed embodiment of the query system 400 is shown in FIG. In this embodiment, the query system 400 includes a connection manager 420, a query engine 430, an index / commit engine 440, and a data layout manager 450, each of which will be described in more detail below.
Generally speaking, a query specifies how a subset of data is selected from a larger set of data, for example through evaluation of one or more data fields of records stored in a self-describing format. For example, the user requests to select all stored records corresponding to file / tesut1 / foo.pdf for further analysis. In response, the user configures a query that specifies the selection of all records whose data field has a data field tagged "path" equal to a particular value, such as "/test1/foo.pdf". In some embodiments, the entire file system content, including the file data stored in file 250 as well as the metadata stored in named stream 260, was created in-band by, for example, filter driver 221. Or, for example, query whether it was generated out of band by a particular content processor 330, or whether the metadata was defined and / or generated outside of file system 205 by application process 112 via API 114, eg, as described above. be able to. Further, in some embodiments where file system content access events are recorded in the event log 270 as described above, these recorded events can also be queried.
The query consists of a query language, which provides a syntax structure for selecting a set of data based on the values of one or more tagged data fields. In some embodiments, a given query language supports procedural functions, such as functions, in addition to, for example, set selection functions. Further, in some embodiments, a given query language supports embedding of procedural routines coded in other programming languages, such as Java® or C, within queries. When the XML format is used to compose file system content, a given application is an XML query (XQuery) language as specified by the World Wide Web Consortium (W3C), or any functional XQuery criteria or The variant composes a query to select specific file system content. However, any suitable query language may be used.
As described above, in the illustrated embodiment, process 112 generates a query and passes it to query system 400 via API 114. In some embodiments, the query system 400 is configured to support some process 112 with outstanding parallel queries at a given time. Further, in some embodiments, the query process 112 submits the query from a remote computer system over the network. Further, the query process 112 may need to be authenticated in some embodiments, for example to restrict access to the query system 400. In one embodiment, the connection manager 420 is configured to manage the overhead of establishing and maintaining a connection between the query process 112 and the query system 400. For example, Connection Manager 420 is configured to provide authentication interfaces (such as username and password interfaces), which causes query process 112 to set these privileges to execute queries. Further, in one embodiment, the connection manager 420 is configured to hold all the information necessary to support connection-based or session-based semantics for query process 112. For example, Connection Manager 420 maintains a data structure that maps ongoing queries to the requesters involved so that the query results are directed to the correct query process 112. In some embodiments, Connection Manager 420 is configured to load balance query requests, for example by distinguishing requests from multiple instances of query engine 430 to improve overall query throughput. To.
In one embodiment, the query engine 430 is configured to parse and evaluate the query presented to the query system 400 via the connection manager 420. For example, query engine 430 can receive queries requesting the names of all files 250 modified by a particular user over time. The query engine 430 can parse the query for syntactic validity and return an error state if the query is malformed. In some embodiments, the query engine 430 also decomposes the query into multiple queries and / or performs structural transformations into the queries in order to optimize the queries in terms of performance. The query engine 430 then examines the metadata records stored in the named stream 260 to identify the file 250 that meets certain criteria and returns the names of these files to query process 112. Many implementations of the query engine 430, configured for query parsing and evaluation, are possible.
In some embodiments, the query engine 430 interacts directly with the storage management system 200 to access file system content in response to query evaluation. However, in some cases, query evaluation performance is improved by creating one or more indexes of file system content and using these indexes to assist in query evaluation. In the illustrated embodiment, the index / commit engine 440 is configured to generate and hold these indexes and further provide index information to the query engine 430 during query evaluation.
Generally speaking, an index can be any data structure that organizes a collection of data according to some aspect or attribute, facilitating querying for data by the indexed aspect or attribute. For example, in one embodiment, the index is a list of the names of all 250 files defined in file system 205, organized alphabetically. In some embodiments, multiple indexes of file system content can be used. For example, if you frequently query file system content by name, associated user, content creation / modification time, you may create individual indexes that sort or organize the file system content by each of these attributes. In some embodiments, a more complex indexing scheme can be used that includes an index that combines multiple content attributes into a composite state space. In addition, indexes can be implemented with any suitable data structure, including lists, tables, trees, and high-level data structures.
The index created by the index / commit engine 400 stores itself in file system 205. In some embodiments, these indexes are stored separately from other file system content. In such an embodiment, the data layout manager 450 is configured to track the position of the index in the file system 205. In one embodiment, the data layout manager 450 is configured to bypass the filter driver 221 while accessing the index-related storage so that in-band metadata corresponding to index access is not generated. In such an embodiment, some inconsistencies, including indexing and metadata, are avoided. For example, if the index / commit engine 440 contains metadata for a given index, such as a modification timestamp, within a given index, and then attempts to write the given index to storage via the filter driver 221. The metadata of a given index following a write no longer matches the content of a given index, for example if the filter driver 221 creates a new modification timestamp in response to a write operation.
In some embodiments, the query process 112 uses the query to modify the file system content via the query system 400. For example, a query is used to select a set of data items, such as file 250, from the available file system content. The selected data item is then modified, but instead of modifying directly to the file system 205 propagated to the storage device 230, the query system 400 coordinates the data update, thereby modifying the file system content. Present an alternative route for. However, in embodiments where there are multiple paths for modifying file system content, coordination between these paths is necessary to prevent conflicting modifications to common data. In one embodiment, the index / commit engine 440 is configured to implement a commit protocol (eg, two-phase commit) to ensure that updates to file system content match.
The index maintained by the index / commit engine 440 is generally a derivative of the file system content, but as a result, the file system content changes (either by updating through the query system 400, by the activity of the content processor 300, or by the activity of the content processor 300. One or more indexes corresponding to the modified content may no longer accurately reflect the new state of the content (either by process 112, which interacts directly with the file system 205). There is. For example, if the index / commit engine 440 contains an index of file system content for each filename and a given file 205 is renamed by process 112, the filename-based index can be out of date after the rename. There is sex. Generally speaking, if an index is valid with respect to the state of the index data, then the index is said to preserve reference consistency with respect to the index data.
When the indexed file system content changes, the index / commit engine 440 is configured to preserve the reference consistency of that index by updating the associated index to reflect this change. In one embodiment, the index / commit engine 440 works with the content processing daemon 320 in the content processing system 300 or a particular content processor 330 to detect changes in file system content and index in response. Configured to update. For example, in one embodiment, the content processing daemon 320 is configured to detect that some change has occurred to the file system content, such as by scanning the event log 270. In response to the detection of a file system content access event that could result in changes in the content (eg, an event that causes the creation, modification, or deletion of file system content), the content processing daemon 320 raises the detected event. It is configured to notify the index / commit engine 440. In response, the index / commit engine 440 updates one or more indexes affected by the detected event to maintain these reference consistency. For example, if a particular file 250 is deleted, the content processing daemon 320 finds an event record in the event log 270 that corresponds to the deletion and notifies the index / commit engine 440 of the event and the deleted file 250. To do. The index / commit engine 440 then modifies the index to maintain the removal of references to the deleted file 250.
In another embodiment, one or more specific content processors 330 are configured to monitor the file system content corresponding to the specific index maintained by the index / commit engine 440. For example, in one embodiment, the index / commit engine 440 has the structure and content of a particular index, such as self-describing data fields associated with the index (eg, filename, file size, file signature, etc.) and their current values. Is notified to a given content processor 330. The content processor 330 is then configured to monitor file system content access events for events related to the structure and content of a particular index, notifying the index / commit engine 440 of only those related events. Upon receiving such notification, the index / commit engine 440 updates the associated index to preserve its reference consistency, for example by adding or removing information from the index.
FIG. 9 shows one embodiment of the method of operation of the storage system 150 including the query system 400. Referring collectively to FIGS. 1 to 4, 8 and 9, the operation begins at block 900, where file system content such as file data or metadata is stored. In one embodiment, the file system content includes both file data and metadata. In some embodiments, the query system 400 is configured to generate one or more indexes of file system content as described above (block 902), but in other embodiments this step is omitted. be able to.
Following the storage of file system content, a file system content access event is detected within the band (block 904). For example, the file system content access event is detected in the band by the filter driver 221 as described above. As mentioned above, in some embodiments, the initial storage of file system content is a file system content access event that can detect itself. For example, the file creation operation is a file system content access event that can be detected in step 902.
Metadata records are generated in response to detection of file system content access events (block 906). For example, in one embodiment, the filter driver 221 will generate a metadata record that contains information related to the event or file system content being accessed, such as a time stamp, file signature, identity of the process that generates the event, and so on. It is composed of. In one embodiment, such records are stored within a particular named stream 260. Further, in some embodiments, the event record is generated in response to event detection. Such an event record is stored in, for example, the event log 270. In one embodiment, the metadata records and / or event records generated in response to event detection are stored in an extensible self-describing data format, such as the XML format, as described above.
In embodiments where file system content is indexed, notifications of file system content access events can be received (block 908) and reference consistency of relevant indexes is maintained for file system content access events (block 910). .. For example, the content processing daemon 320 is configured to notify the index / commit engine 440 of all file system content access events, or a particular content processor 330 is maintained by the index / commit engine 440 as described above. It is configured to monitor these index-related events. In response to receiving notifications of relevant events, the index / commit engine 440 is configured to update the relevant index to maintain its reference consistency as described above. These steps can be omitted in embodiments that do not use indexing.
Query the file system content following the generation of the metadata record (block 912). For example, the query system 400 is configured to respond to queries submitted by process 112 by querying file data and / or metadata. In an embodiment where the file system content is stored in XML format, the query is generated in XML query (XQuery format).
Although the embodiments have been described in considerable detail above, a full understanding of the above disclosure will reveal many modifications and modifications to those skilled in the art. The appended claims shall be construed to include all such modifications and amendments.
<figref num="1">It is a block diagram which shows one Embodiment of a storage system.</figref><figref num="2">It is a block diagram which shows one embodiment of a software-based storage system architecture and an interface to a storage device.</figref><figref num="3">It is a block diagram which shows one Embodiment of a storage management system.</figref><figref num="4">FIG. 6 is a block diagram illustrating one embodiment of a file system configured to store files and associated metadata.</figref><figref num="5">It is a flow chart which shows one Embodiment of the method of metadata generation.</figref><figref num="6">It is a block diagram which shows one Embodiment of a content processing system.</figref><figref num="7">It is a flow diagram which shows one Embodiment of the operation method of the storage system including the content processing system.</figref><figref num="8">It is a block diagram which shows one Embodiment of a query system.</figref><figref num="9">It is a flow diagram which shows one Embodiment of the operation method of the storage system including the inquiry system.</figref>
Code description
205 file system, 221 filter driver, 250 files, 260 named streams, 270 event logs, 255 files
9 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9
Every citation, both ways
| Document | Relation | Office | Cited during |
|---|---|---|---|
| JP2002244915A | Cites | Japan | Examiner |
| JP2003244615A | Cites | Japan | Examiner |
| JP2002244915A | Cites | Japan | – |
| JP2003244615A | Cites | Japan | – |
15 members in 5 offices
Priority claims14
| Document | Office | Kind | Date |
|---|---|---|---|
| 10723704 | United States of America | – | |
| 72370403 | United States of America | A | |
| 72370403 | United States of America | A | |
| 10862505 | United States of America | – | |
| 86250504 | United States of America | A | |
| 86250504 | United States of America | A | |
| 2004039038 | United States of America | W | |
| 2004039038 | United States of America | W | |
| 2003723704 | – | – | – |
| 2004862505 | – | – | – |
| 2004039038 | – | – | – |
| US20030723704 | – | – | – |
| US20040862505 | – | – | – |
| WO2004US39038 | – | – | – |
Members15
| Document | Office | Kind | |
|---|---|---|---|
| US2005114338A1 | United States of America | A1 | |
| US2005114363A1 | United States of America | A1 | |
| US2005114381A1 | United States of America | A1 | |
| WO2005055093A2 | World Intellectual Property Organization (WIPO) | A2 | |
| WO2005055093A3 | World Intellectual Property Organization (WIPO) | A3 | |
| EP1687745A2 | European Patent Office (EPO) | A2 | |
| CN1906613A | China | A | |
| JP2007515002A | Japan | A | |
| US7328217B2 | United States of America | B2 | |
| US2008126374A1 | United States of America | A1 | |
| US7653647B2 | United States of America | B2 | |
| CN1906613B | China | B | |
| US7912866B2 | United States of America | B2 | |
| JP4782017B2This record | Japan | B2 | |
| US8484257B2 | United States of America | B2 |
28 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Written notification of registration of transferJAPANESE INTERMEDIATE CODE: R350R350 | R350 | |
| Request for change of ownership or part of ownershipJAPANESE INTERMEDIATE CODE: R313113S111 | S111 | |
| Request for change of ownership or part of ownershipJAPANESE INTERMEDIATE CODE: R313111S111 | S111 | |
| Cancellation because of no payment of annual feesLAPS | LAPS | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Renewal fee payment (event date is renewal date of database)FPAY | FPAY | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| First payment of annual fees (during grant procedure)JAPANESE INTERMEDIATE CODE: A61A61 | A61 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Decision of grant or rejection writtenTRDD | TRDD | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A821A521 | A521 | |
| Notification of resignation of power of attorneyJAPANESE INTERMEDIATE CODE: A7424RD04 | RD04 | |
| Notification of appointment of power of attorneyJAPANESE INTERMEDIATE CODE: A7423RD03 | RD03 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Request for written amendment filedJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Written permission of extension of timeJAPANESE INTERMEDIATE CODE: A602A602 | A602 | |
| Written request for extension of timeJAPANESE INTERMEDIATE CODE: A601A601 | A601 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Written request for application examinationJAPANESE INTERMEDIATE CODE: A621A621 | A621 |
Numbers
- Publication
- 4782017
- Publication, DOCDB
- 4782017
- Publication, EPODOC
- JP4782017B
- Application
- 2006541574
- Application, DOCDB
- 2006541574
- Application, EPODOC
- JP20060541574
Titles2
- Japanese
- 拡張可能なファイルシステムメタデータの作成及びファイルシステムコンテンツ処理のためのシステムと方法
- English
- Systems and methods for creating extensible file system metadata and processing file system content
Classification
- CPC, 3
- G06F16/10
- Y10S707/99942
- Y10S707/99933
- IPC, 3
- G06F12 00
- G06F17 00
- G06F17 30
