JP4768009B2

JP4768009B2 - How to store less redundant data using a data cluster

Info

Publication number: JP4768009B2
Application number: JP2008500011A
Authority: JP
Inventors: ロスニールウィリアムズ
Original assignee: ロックソフトリミテッド
Priority date: 2005-03-11
Filing date: 2006-03-10
Publication date: 2011-09-07
Anticipated expiration: 2026-03-10
Also published as: JP2008537209A

Description

本発明は、コンピュータ・システムにおいて記憶空間が少なくてすむ形式でデータを格納する方法および装置に関する。 The present invention relates to a method and apparatus for storing data in a form that requires less storage space in a computer system.

従来のコンピュータ記憶システムは、通常、ファイル・システム内に名前付きファイルとしてバイトのシーケンスを格納している。多くのファイルは相互に非常に似ている場合があり、データの大部分１３０、１３２を共有している場合がある（図１３）のに、これらのシステムはこの冗長性を除去することができない。それどころか、これらのシステムは、同じデータの多数のコピー１３０、１３２を保持しながら各ファイル１４０、１４２を別々に格納していることもある（図１４）。 Conventional computer storage systems typically store a sequence of bytes as a named file in the file system. Many files may be very similar to each other and may share most of the data 130, 132 (FIG. 13), but these systems cannot remove this redundancy. . Rather, these systems may store each file 140, 142 separately while maintaining multiple copies 130, 132 of the same data (FIG. 14).

従来のファイル・システムの中には、個々のファイルを圧縮するために、（ＧＺｉｐのような）従来の損失を起こさないテキスト圧縮アルゴリズムを組み込んでいるものがあるが、これは「鍵穴」冗長除去技術と見なすことができる。何故なら、この技術は、ファイル・システムを全体として分析するのではなく、ある時点で１つのファイルの冗長性を分析するからである。これらの従来のテキスト圧縮アルゴリズムは、ファイル・システムの異なる部分の２つの類似しているファイル１３０、１３２のような遠く離れているデータ１５０、１５２間の類似性を見つけることができない場合がある（図１５）。 Some traditional file systems incorporate non-lossy text compression algorithms (such as GZip) to compress individual files, but this eliminates "keyhole" redundancy It can be regarded as technology. Because this technique does not analyze the file system as a whole, it analyzes the redundancy of a single file at some point. These conventional text compression algorithms may not be able to find similarities between distant data 150, 152 such as two similar files 130, 132 in different parts of the file system ( FIG. 15).

そこで、データのその反復シーケンスのいくつかを識別し、格納しているこの反復データのコピーの数を低減することができる形式でデータを表示する方法および装置が求められている。 Accordingly, there is a need for a method and apparatus for identifying some of that repetitive sequence of data and displaying the data in a format that can reduce the number of stored copies of this repetitive data.

データの反復シーケンスのコピーの数を低減するような方法で、いくつかの異なるバイナリ・ラージ・オブジェクト（ＢＬＯＢ）１０、１２を表示するために、２つ以上のＢＬＯＢ表示により各反復シーケンスを参照することができる表示を使用することができる。図１６は、このことを達成することができる１つの方法を示す。この実施形態の場合には、各ＢＬＯＢ１６０、１６２はサブブロックと呼ばれる部分Ａ、Ｂ、Ｃ、Ｄ、Ｅ、Ｆ、Ｇに分割され、サブブロックの複製１６４、１６６は識別され、１回だけ格納される。このフレームワークにおいては、下記の問題が解決される。すなわち、ＢＬＯＢをサブ分割する方法、結果として得られるサブブロックを格納する方法、およびサブブロックの複製を識別するための方法。 Reference each repeated sequence with two or more BLOB displays to display several different binary large objects (BLOBs) 10, 12 in such a way as to reduce the number of copies of the repeated sequence of data. A display that can be used. FIG. 16 shows one way in which this can be achieved. In this embodiment, each BLOB 160, 162 is divided into parts A, B, C, D, E, F, G called sub-blocks, and sub-block duplicates 164, 166 are identified and stored only once. Is done. This framework solves the following problems: That is, a method for subdividing the BLOB, a method for storing the resulting subblock, and a method for identifying duplicate subblocks.

本発明のある態様によれば、格納するデータの各ＢＬＯＢ１０、１２は、分割方法によりサブブロックＡ〜Ｊに分割される（図１）。種々の分割方法を使用することができるが、特に、データを固定長のサブブロック６０〜６５に分割する固定長分割方法を使用することもできるし（図６）、またはデータ自身により定めた位置で（図１）、データを可変長のサブブロックＥ、Ｆ、Ｇ、Ａ、Ｂ、Ｃ、Ｄに分割する可変長分割方法を使用することもできる（図１０）。本発明者と同じ発明者であるＷｉｌｌｉａｍｓの米国特許第５，９９０，８１０号に、この後者の方法の一例が開示されている。この米国特許は、参照により本明細書に組み込まれ、図３７に示す。 According to an aspect of the present invention, each BLOB 10, 12 of data to be stored is divided into sub-blocks A to J by a dividing method (FIG. 1). Various division methods can be used. In particular, a fixed-length division method for dividing data into fixed-length sub-blocks 60 to 65 can be used (FIG. 6), or a position determined by the data itself. (FIG. 1), it is also possible to use a variable-length division method that divides data into variable-length sub-blocks E, F, G, A, B, C, and D (FIG. 10). An example of this latter method is disclosed in US Pat. No. 5,990,810 to Williams, the same inventor as the inventor. This US patent is incorporated herein by reference and shown in FIG.

サブブロックは、冗長除去の単位になり、ある実施形態の場合には、システムは、せいぜい一度だけ一意の各サブブロックを格納する。他の実施形態の場合には、一意の各サブブロックのコピーの数は低減するが、２以上の場合がある。 A sub-block is a unit of redundancy elimination, and in one embodiment, the system stores each unique sub-block at most once. In other embodiments, the number of copies of each unique sub-block is reduced, but may be two or more.

例示的実施形態の場合には、ＢＬＯＢのサブブロックは、サブブロック・クラスタ２０、２２、２４と呼ばれるグループ内に格納される（図２）。各ＢＬＯＢは、それぞれが１つのクラスタ２０、２２、２４内のサブブロックの隣接シーケンスを識別するレコード（「スパン・レコード」）３０、３１、３２の順序付きリスト（またはツリー）により表示することができる（図３および図４）。ＢＬＯＢ１０は、スパン３０、３１、３２のリストにより識別されたシーケンスの連結として表示することができ（図３および図４）、各スパンが参照したサブブロック内のサブブロック・コンテンツを検索するスパンのＢＬＯＢのリストを順次チェックすることにより、記憶装置から検索することができる。 In the exemplary embodiment, the BLOB sub-blocks are stored in groups called sub-block clusters 20, 22, 24 (FIG. 2). Each BLOB may be represented by an ordered list (or tree) of records (“span records”) 30, 31, 32, each identifying an adjacent sequence of sub-blocks within one cluster 20, 22, 24. Yes (FIGS. 3 and 4). BLOB 10 can be displayed as a concatenation of the sequences identified by the list of spans 30, 31, 32 (FIGS. 3 and 4), with spans searching for sub-block content within the sub-block referenced by each span. By sequentially checking the list of BLOBs, it is possible to retrieve from the storage device.

例示的実施形態においては、クラスタ２０、２２、２４は、２つ以上のＢＬＯＢＸおよびＹからのサブブロックを含むこともできるし（図４）、ＢＬＯＢのサブブロックは、２つ以上のクラスタ内に常駐することもできる（図３）。例示的実施形態において、ＢＬＯＢのサブブロックを１つまたは複数のクラスタ内に順次格納することができる（図２）。これによりＢＬＯＢ検索の効率が改善される。何故なら、ＢＬＯＢ内のサブブロックの全シーケンスを、１回の順次読出動作でディスクから読み出すことができるからである。このことは、各サブブロックを探してランダム・アクセス・ディスク・シークを行うよりも遥かに効率的である。 In the exemplary embodiment, clusters 20, 22, and 24 may include sub-blocks from two or more BLOBs X and Y (FIG. 4), or BLOB sub-blocks may be contained within two or more clusters. (Fig. 3). In an exemplary embodiment, BLOB sub-blocks may be stored sequentially in one or more clusters (FIG. 2). This improves the efficiency of BLOB search. This is because the entire sequence of sub-blocks in the BLOB can be read from the disk with a single sequential read operation. This is much more efficient than searching for each sub-block and doing a random access disk seek.

例示的実施形態においては、同じまたは異なるＢＬＯＢ内の異なるスパンは、同じサブブロックを含む（図４）。これにより冗長性を低減することができる。何故なら、同じサブブロックを含むＢＬＯＢは、（クラスタ内の）同じサブブロックを指すスパンにより表示することができるからである。 In the exemplary embodiment, different spans in the same or different BLOBs include the same sub-block (FIG. 4). Thereby, redundancy can be reduced. This is because BLOBs containing the same sub-block can be represented by spans pointing to the same sub-block (within a cluster).

本発明のさらに他の態様によれば、各クラスタは、クラスタが使用するスペースの大きさを低減するためにデータ圧縮方法により圧縮される。これを行う最も簡単な方法は、全クラスタを圧縮することである。いくつかの実施形態（特に大きなクラスタを使用する実施形態の場合には）においては、全クラスタ（またはサブブロックを読み出す前のクラスタの少なくとも一部）を圧縮解除しなくても、クラスタ内のサブブロックにアクセスすることができるように、クラスタの各部分（例えば、個々のサブブロックまたはサブブロックの一続きの部分）を圧縮することが望ましい場合がある。 According to yet another aspect of the invention, each cluster is compressed by a data compression method to reduce the amount of space used by the cluster. The simplest way to do this is to compress the entire cluster. In some embodiments (especially in the case of using large clusters), the entire cluster (or at least a portion of the cluster prior to reading the sub-block) may be decompressed without subcompression. It may be desirable to compress each part of the cluster (eg, an individual sub-block or a series of sub-blocks) so that the block can be accessed.

本発明のさらに他の態様によれば、各クラスタ内のサブブロックのディレクトリ７０が各クラスタに対して生成され、（通常は開始のところの）クラスタ内に格納されるか（図７）、または別々に８０、８２（図８）内に格納される。ディレクトリは、例えば、サブブロックの前に各サブブロックのメタデータを格納することにより、クラスタ全体に分配することもできる（図９）。ディレクトリは、そのハッシュ、長さ、サブブロック識別子、およびクラスタ内のその位置のような、各サブブロックに対する種々のメタデータを含むことができる。 According to yet another aspect of the invention, a sub-block directory 70 in each cluster is created for each cluster and stored in the cluster (usually at the beginning) (FIG. 7), or Separately stored in 80 and 82 (FIG. 8). Directories can also be distributed throughout the cluster, for example by storing the metadata of each sub-block before the sub-block (FIG. 9). A directory may contain various metadata for each subblock, such as its hash, length, subblock identifier, and its location within the cluster.

本発明のさらに他の態様によれば、２つ以上のＢＬＯＢが共有するサブブロックが識別される。例示的実施形態においては、サブブロックのコンテンツまたはサブブロック・ハッシュ（サブブロックのコンテンツのハッシュ）をクラスタ５２、５４、５６にマッピングする（または関連付ける）サブブロック・インデックス５０が維持される。格納動作中、格納される各サブブロックが、サブブロック・インデックス内で参照される。存在する場合には、サブブロックは再度格納されない。サブブロックが存在しない場合には、サブブロックはクラスタ内に格納され、それに対するエントリがサブブロック・インデックスに追加される。いずれの場合も、新しいサブブロックがスパン５８により参照される。 According to yet another aspect of the invention, sub-blocks shared by two or more BLOBs are identified. In the exemplary embodiment, a sub-block index 50 is maintained that maps (or associates) sub-block content or sub-block hash (sub-block content hash) to clusters 52, 54, 56. During the store operation, each stored sub-block is referenced in the sub-block index. If present, the sub-block is not stored again. If the subblock does not exist, the subblock is stored in the cluster and an entry for it is added to the subblock index. In either case, the new sub-block is referenced by span 58.

本発明のある態様によれば、特定のサブブロックが記憶装置内にすでに存在していることをインデックスが示す場合には、一致するサブブロックのクラスタがアクセスされ、クラスタ内の一致するサブブロックの後のサブブロックが、格納するＢＬＯＢ内の一致するサブブロックの後のサブブロックと比較される（図１０）。この比較はインデックスにアクセスしないで行うことができ、実際には、サブブロックを含んでいるクラスタが、サブブロック・ハッシュを含むサブブロック・ディレクトリを有している限り、実際のサブブロック・コンテンツ・データにアクセスしないで行うことができる。
用語
欠落サブブロック：記憶装置内に存在していないサブブロック
ＢＬＯＢ（バイナリ・ラージ・オブジェクト）：データのゼロまたはそれ以上のバイト（またはビット）の有限シーケンス。その名前にも関わらず、ＢＬＯＢは必ずしも大きくはない。ＢＬＯＢは、数ビットまたはバイトのように小さいものであってもよいし、またはギガバイトのように大きいものであってもよい。 According to one aspect of the invention, if the index indicates that a particular sub-block already exists in the storage device, the cluster of matching sub-blocks is accessed and the matching sub-block in the cluster is accessed. The later sub-block is compared with the subsequent sub-block after the matching sub-block in the BLOB to store (FIG. 10). This comparison can be done without accessing the index; in fact, as long as the cluster containing the subblock has a subblock directory containing the subblock hash, the actual subblock content This can be done without accessing the data.
Term Missing Subblock: A subblock that does not exist in storage BLOB (Binary Large Object): A finite sequence of zero or more bytes (or bits) of data. Despite its name, BLOB is not necessarily large. A BLOB may be as small as a few bits or bytes, or as large as a gigabyte.

ＢＬＯＢレコード：特定のＢＬＯＢについての情報を記録している記憶装置内に維持されているレコード。また、ＢＬＯＢレコードは、ＢＬＯＢコンテンツを定義するスパンのリスト（またはツリー）を含むこともできるし、または参照することもできる。 BLOB record: A record maintained in a storage device that records information about a particular BLOB. A BLOB record can also include or reference a list (or tree) of spans that define BLOB content.

ＢＬＯＢテーブル：ＢＬＯＢ識別子（例えば、制限なしに、ＢＬＯＢハッシュ）をＢＬＯＢレコードに関連付けるデータ構造
クラスタ：「サブブロック・クラスタ」の短縮語。関連するサブブロックのグループ。クラスタは、クラスタ内のサブブロックについての情報を提供する関連サブブロック・ディレクトリを有することができる。 BLOB table: A data structure that associates a BLOB identifier (eg, BLOB hash, without limitation) with a BLOB record. A group of related sub-blocks. A cluster can have an associated subblock directory that provides information about the subblocks in the cluster.

クラスタ・サブブロック・ディレクトリ：クラスタ内のサブブロックについての情報を提供するメタデータの集合体。サブブロックのメタデータは、サブブロックの長さ、ハッシュ、識別子および基準カウントを含むことができる（しかし、含むことができるものはこれらに限定されない）。 Cluster subblock directory: A collection of metadata that provides information about subblocks in a cluster. Sub-block metadata may include (but is not limited to) sub-block length, hash, identifier, and reference count.

隣接する：物事の順序付きグループ内の２つの物事が隣り合っている場合には、隣接するという。Ｎの物事が正確にＮ−１の隣り合った１対の物事を含んでいる場合には（すなわち、Ｎの物事が１つの連続している一続きの部分として表される場合には）、物事の順序付きグループ内のＮという物事は隣接している。 Adjacent: Two things in an ordered group of things are said to be adjacent if they are next to each other. If N things contain exactly N-1 adjacent pairs of things (ie if N things are represented as one continuous stretch), Things N in an ordered group of things are adjacent.

隣接サブブロック：隣り合っている場合には、あるコンテキスト（例えば、ＢＬＯＢまたはクラスタ）において、２つのサブブロックは隣接している。Ｎという物事が正確にＮ−１の隣り合った１対のサブブロックを含んでいる場合には（すなわち、サブブロックが１つの連続している一続きの部分となっている場合には）、あるコンテキストにおいてＮのサブブロックは隣接している。 Adjacent sub-blocks: When adjacent, two sub-blocks are adjacent in a context (eg, BLOB or cluster). If N includes exactly N-1 adjacent pairs of sub-blocks (ie, if the sub-block is a single continuous sequence), In some contexts, N subblocks are adjacent.

ディレクトリ：クラスタ・サブブロック・ディレクトリ参照
ディスク：コンピュータが使用するランダム・アクセス記憶媒体。通常、ディスクという用語は、磁化したデータを保持している金属の回転円盤（ハードディスク）を意味する。本明細書においては、ディスクという用語は、メモリよりかなり遅いランダム・アクセス記憶媒体を意味するようにもっと広義に解釈することができる。 Directory: Cluster sub-block directory reference Disk: Random access storage medium used by computers. Usually, the term disk means a metal rotating disk (hard disk) holding magnetized data. As used herein, the term disk can be interpreted more broadly to mean a random access storage medium that is much slower than memory.

固定長分割方法：データを固定長サブブロックに分割するデータを分割するための方法。例えば、固定長分割方法は、ＢＬＯＢを５１２バイトのサブブロックに分割することができる。 Fixed-length division method: A method for dividing data into data that is divided into fixed-length sub-blocks. For example, the fixed length division method can divide a BLOB into 512-byte sub-blocks.

ハッシュ：ハッシュ・アルゴリズムが生成したバイト（またはビット）の固定長シーケンス。サブブロックのハッシュは、サブブロックを索引し、比較するためのサブブロックを表すものとして使用することができる。 Hash: A fixed-length sequence of bytes (or bits) generated by a hash algorithm. A sub-block hash can be used to represent a sub-block for indexing and comparing sub-blocks.

ハッシュ・アルゴリズム：バイト（またはビット）の有限シーケンスを受け入れ、入力シーケンスに高度に依存するバイト（またはビット）の有限シーケンスを生成するアルゴリズム。通常、ハッシュ・アルゴリズムは、特定の固定長の出力を生成する。ハッシュ・アルゴリズムは、シーケンスを直接比較しなくても、データの２つのシーケンスが同じであるか否かをチェックするための試験に使用することができる。実際に暗号化ハッシュを使用すれば、そのハッシュが同じである場合、２つのサブブロックが同じであると結論することができる。ハッシュ・アルゴリズムは、ＢＬＯＢ識別子を生成し、サブブロックを比較し、ハッシュ・テーブル・キーを生成するために、例示的実施形態において使用することができる。 Hash algorithm: An algorithm that accepts a finite sequence of bytes (or bits) and generates a finite sequence of bytes (or bits) that is highly dependent on the input sequence. Usually, a hash algorithm produces a specific fixed length output. The hash algorithm can be used for testing to check whether two sequences of data are the same without directly comparing the sequences. In fact, if a cryptographic hash is used, it can be concluded that the two sub-blocks are the same if the hash is the same. A hash algorithm can be used in the exemplary embodiment to generate a BLOB identifier, compare sub-blocks, and generate a hash table key.

サブブロックのハッシュ：サブブロック・ハッシュ参照
インデックス：サブブロック・インデックス参照
インデックス・バケット：ハッシュ・テーブルを使用してサブブロック・インデックスを実施する実施形態の場合には、ハッシュ・テーブルを、それぞれが空であるかエントリを含み、それぞれが一定数のエントリ・スロットを含むバケットのアレイとして構成することができる。インデックス・バケットの１つの目的は、ハッシュ・テーブルを、ランダム・アクセス・ディスク動作の回数を低減するために、グループとしてディスクから読み出し、ディスクに書き込むことができる部分に構成することである。
インデックス・エントリ：サブブロック・インデックス内のレコード。ある実施形態の場合には、インデックス・レコードは、インデックス・キーおよびインデックス値を含む。ある実施形態の場合には、インデックス・レコードは、インデックス・キーの一部およびインデックス値を含む。ある実施形態の場合には、インデックス・レコードはインデックス値だけを含む。ある実施形態の場合には、インデックス・レコードは値を含まないで、キーの一部または全部を含む。 Subblock Hash: Subblock Hash Reference Index: Subblock Index Reference Index Bucket: For embodiments that implement a subblock index using a hash table, each hash table is empty Can be configured as an array of buckets, each containing a certain number of entry slots. One purpose of the index bucket is to organize the hash table into portions that can be read from and written to the disk as a group to reduce the number of random access disk operations.
Index entry: A record in a sub-block index. In some embodiments, the index record includes an index key and an index value. In some embodiments, the index record includes a portion of the index key and an index value. In some embodiments, the index record contains only the index value. In some embodiments, the index record does not contain a value and contains some or all of the key.

インデックス・キー：サブブロックについての情報を検索するために、サブブロック・インデックスに提供されるサブブロックについての情報。ある実施形態の場合には、この情報はインデックス・エントリの位置を発見し、読み出すことにより検索される。 Index key: Information about a sub-block that is provided to the sub-block index to retrieve information about the sub-block. In one embodiment, this information is retrieved by locating and reading the index entry.

インデックス値：サブブロック（またはその一例がそのハッシュであるサブブロックの派生物）をインデックスで参照した場合に、インデックスによりサブブロックについて生成された情報。ある実施形態の場合には、この値は、ディスク上のサブブロックの位置からなる。他の実施形態の場合には、インデックスの唯一の目的がキーの有無を記録することである場合には、値が存在しない場合がある。ある実施形態の場合には、この値は単にクラスタ数からなる。 Index value: Information generated about a sub-block by the index when the sub-block (or a derivative of the sub-block whose example is the hash) is referenced by the index. In some embodiments, this value consists of the location of the sub-block on the disk. In other embodiments, the value may not exist if the only purpose of the index is to record the presence or absence of a key. In some embodiments, this value simply consists of the number of clusters.

サブブロックの長さ：サブブロック・コンテンツ内のバイト（またはビット）数
線形探索：１つずつ集合体内のオブジェクトをチェックすることによる、およびチェックする次のオブジェクトの選択が前のチェックの結果により影響を受けない場合の、オブジェクトの集合体内の１つのオブジェクトに対する探索方法。
スパンのリスト：スパンの順序付きリスト。このようなリストは、ＢＬＯＢのコンテンツを表示するために使用することができる。 Subblock length: the number of bytes (or bits) in the subblock content Linear search: by checking the objects in the collection one by one, and the selection of the next object to check is affected by the result of the previous check A search method for one object in a collection of objects when it is not.
List of spans: An ordered list of spans. Such a list can be used to display BLOB content.

一致する一続きの部分：（例えば、格納しているＢＬＯＢ内に存在してもよい）サブブロックの他のシーケンスと一致する（クラスタ内の）サブブロックのシーケンス。ある実施形態の場合には、サブブロックのシーケンスは隣接している。 A sequence of matches: a sequence of sub-blocks (within a cluster) that matches other sequences of sub-blocks (eg, which may be present in the stored BLOB). In some embodiments, the sequence of sub-blocks is contiguous.

メモリ：通常、ランダム・アクセス・メモリ（ＲＡＭ）を参照するコンピュータが使用するランダム・アクセス記憶媒体。本明細書においては、この用語は、「ディスク」よりかなり速いランダム・アクセス記憶媒体を意味するようにもっと広義に解釈することができる。 Memory: A random access storage medium typically used by computers that reference random access memory (RAM). As used herein, the term can be interpreted more broadly to mean a random access storage medium that is significantly faster than a “disk”.

分割方法：ＢＬＯＢ内の各バイト（またはビット）が、正確に１つのサブブロック内に入るように、ＢＬＯＢを１つまたは複数のサブブロックに分割するための方法。 Dividing method: A method for dividing a BLOB into one or more sub-blocks so that each byte (or bit) in the BLOB falls within exactly one sub-block.

存在サブブロック：記憶装置内に存在するサブブロック。 Existence sub-block: A sub-block present in the storage device.

低冗長：バイト（またはビット）の同一シーケンスのコピー数の任意のタイプのデータ表示での低減である。 Low redundancy: A reduction in the number of copies of the same sequence of bytes (or bits) in any type of data display.

低冗長記憶装置：データのその表示の際に、自身が格納している一組のデータ内の複製データのいくつかを除去する記憶システム。 Low redundancy storage: A storage system that removes some of the duplicated data in the set of data it stores during its display of data.

サブブロックへの参照：サブブロックを識別する１つのデータ。例えば、制限なしで、参照は、コンテンツまたは格納位置によりサブブロックを識別することができる。 Reference to sub-block: A piece of data that identifies a sub-block. For example, without limitation, the reference can identify sub-blocks by content or storage location.

基準計数：あるエンティティがもはや必要なくなった時を判定するための方法。この方法は、エンティティに対して存在する参照の数を記録するカウンタを維持するステップを含む。基準カウントがゼロになった場合には、エンティティを削除することができる。ある実施形態の場合には、ＢＬＯＢおよび／またはサブブロックは基準カウントを有する。 Reference Count: A method for determining when an entity is no longer needed. The method includes maintaining a counter that records the number of references that exist for the entity. If the reference count reaches zero, the entity can be deleted. In some embodiments, the BLOB and / or sub-block has a reference count.

スパン：クラスタ内のサブブロックのシーケンス。ある実施形態の場合には、このシーケンスは隣接している。 Span: A sequence of sub-blocks in a cluster. In some embodiments, this sequence is contiguous.

スパン・レコード：クラスタ内のスパンを識別するレコード。ある実施形態の場合には、スパン・レコードは、クラスタ番号フィールド、開始サブブロック識別子フィールド、および（サブブロックまたはバイトの）スパン長フィールドを含む。 Span record: A record that identifies a span within a cluster. In some embodiments, the span record includes a cluster number field, a starting subblock identifier field, and a span length field (in subblocks or bytes).

記憶装置：低冗長記憶装置参照。 Storage device: See low redundancy storage device.

サブブロック：索引、比較および／または冗長除去のための単位として識別されたバイト（またはビット）のシーケンス。ＢＬＯＢはサブブロックに分割することができる。 Sub-block: A sequence of bytes (or bits) identified as a unit for indexing, comparison and / or redundancy removal. BLOB can be divided into sub-blocks.

サブブロック・クラスタ：一緒に格納している１つまたは複数のサブブロックのグループ。「クラスタ」とも呼ばれる。 Subblock cluster: A group of one or more subblocks stored together. Also called “cluster”.

サブブロック・コンテンツ：サブブロックのメタデータとは異なるサブブロックの実際のデータ。 Sub-block content: actual data of a sub-block different from the sub-block metadata.

サブブロック・ディレクトリ：クラスタ・サブブロック・ディレクトリ参照。 Subblock directory: Cluster subblock directory reference.

サブブロック満了日：サブブロックをユーザが必要としないことを保証された場合に、最も初期の日付を定義するサブブロックと関連する１つのメタデータ。 Subblock Expiration Date: A piece of metadata associated with the subblock that defines the earliest date when it is guaranteed that the user does not need the subblock.

サブブロック・ハッシュ：サブブロックへのハッシュ・アルゴリズムの適用結果。サブブロックのハッシュは、例えば、サブブロックを索引および／または比較するために、サブブロックを表すものとして使用することができる。 Subblock hash: The result of applying a hash algorithm to a subblock. A subblock hash may be used to represent a subblock, for example, to index and / or compare subblocks.

サブブロック識別子：サブブロックに関連する１つのメタデータ。識別子はクラスタ内のサブブロックに対して一意のものであり、それ故、そのクラスタ内のサブブロックを一義的に識別するために使用することができる。ある実施形態の場合には、異なるクラスタ内のサブブロックは、同じ識別子を有することができる。 Sub-block identifier: One piece of metadata associated with a sub-block. The identifier is unique to the sub-block in the cluster and can therefore be used to uniquely identify the sub-block in that cluster. In some embodiments, sub-blocks in different clusters can have the same identifier.

サブブロック・インデックス：サブブロックの位置（例えば、制限なしで、クラスタ番号（およびまた、おそらくサブブロック識別子））に、サブブロックのハッシュ（またはサブブロック自身）をマッピングする（または他の方法で関連付ける）データ構造。 Sub-block index: maps (or otherwise associates) a sub-block hash (or sub-block itself) to a sub-block location (eg, without limitation, cluster number (and possibly also a sub-block identifier)) )data structure.

サブブロック・メタデータ：サブブロックについての情報。サブブロックのメタデータは、（制限なしに）サブブロックの長さ、サブブロックのハッシュ、サブブロックの識別子、サブブロックの満期日付、およびサブブロックの基準カウントを含むことができる。 Sub-block metadata: information about sub-blocks. The sub-block metadata may include (without limitation) the length of the sub-block, the hash of the sub-block, the identifier of the sub-block, the expiration date of the sub-block, and the reference count of the sub-block.

サブブロック・レコード：１つのサブブロックに対するメタデータを含むクラスタ・サブブロック・ディレクトリ内のレコード。 Subblock record: A record in the cluster subblock directory that contains metadata for one subblock.

サブブロック基準カウント：サブブロックに対する参照の現在数を記録する１つのサブブロック・メタデータ。ある実施形態の場合には、これはサブブロックを含むスパンを定義するスパン・レコードの数である。 Subblock criteria count: One subblock metadata that records the current number of references to a subblock. In one embodiment, this is the number of span records that define the span that contains the subblock.

サブブロック一連番号：サブブロック識別子の形式。例えば、一連番号システムを使用するある実施形態の場合には、特定のクラスタに到着するサブブロックには、第１のサブブロックに対して１から始まり増大する一連番号が割り当てられる。ある実施形態の場合には、サブブロックを削除した場合には、一連番号は再使用されない。これらの実施形態の場合には、一連番号は、クラスタ内のサブブロックを一意に識別する方法を提供する。 Sub-block serial number: Sub-block identifier format. For example, in one embodiment using a sequence number system, a sub-block arriving at a particular cluster is assigned a sequence number starting with 1 and increasing relative to the first sub-block. In some embodiments, the sequence number is not reused when a sub-block is deleted. In these embodiments, the sequence number provides a way to uniquely identify the sub-block within the cluster.

ユーザ：記憶装置内にＢＬＯＢを格納し、検索する１つのソフトウェア。 User: A piece of software that stores and retrieves a BLOB in a storage device.

可変長分割方法：ＢＬＯＢを可変長サブブロックに分割する分割方法。好ましい実施形態の場合には、可変長分割方法は、データをデータのコンテンツが決定する境界のところで分割する。例えば、制限なしに、分割方法は、前のいくつかのバイトが、特定の所定の一定値にハッシュするＢＬＯＢ内の各位置のところのサブブロック境界を定義することができる。 Variable length division method: A division method for dividing a BLOB into variable length sub-blocks. In the preferred embodiment, the variable length splitting method splits the data at the boundaries determined by the data content. For example, without limitation, the partitioning method can define sub-block boundaries at each location in the BLOB where the previous few bytes hash to a certain predetermined constant value.

仮想ブロック装置：オペレーティング・システムが提供する固定長記憶ブロックのアレイからなる装置。仮想装置は、物理デバイスに直接対応することができ、または（例えば、ＲＡＩＤを使用して）１つまたは複数の物理デバイスから構成することができる。 Virtual block device: A device that consists of an array of fixed-length storage blocks provided by the operating system. A virtual device can directly correspond to a physical device or can be composed of one or more physical devices (eg, using RAID).

全キー：小さな派生キーの元として使用されるキー。データ構造が成長し、派生キーが必要になるので、全キーの増大する部分を、派生キーを形成するのに使用することができる。 All keys: Keys that are used as sources for small derived keys. As the data structure grows and derived keys are required, the growing portion of the entire key can be used to form the derived key.

本明細書全体および添付の特許請求の範囲を通して、別段の指示がない限り、「備える」および「含む」という用語、および「備えている」および「含んでいる」という派生語は、「包含」および「除外しないこと」を意味する用語であると理解されたい。例えば、このような用語を記載の整数または整数のグループを参照するために使用した場合には、このような用語は、任意の他の整数または整数のグループの除外を意味しない。 Throughout this specification and the appended claims, unless otherwise indicated, the terms “comprising” and “including”, and the derivatives “comprising” and “including”, It should be understood as a term that means “do not exclude”. For example, when such terms are used to refer to the stated integer or group of integers, such terms do not imply the exclusion of any other integer or group of integers.

本明細書の添付の特許請求の範囲は、本明細書に記載する本発明の広義の記述であり、参照により本明細書に組み込まれる。 The claims appended hereto are a broad description of the invention described herein, which is incorporated herein by reference.

本明細書での任意の従来技術への参照は、このような従来技術が共通の一般的知識の一部を形成しているという容認でもなければ、任意の形式の示唆でもないし、またそのように解釈すべきでもない。 Reference to any prior art herein is neither an admission, nor an indication of any form, and such as that such prior art forms part of the common general knowledge. Should not be interpreted.

添付の図面を参照しながら、以下に本発明の特定の実施形態についてさらに詳細に説明する。これらの実施形態は、説明のためのものであって、本発明の範囲を制限するためのものではない。他の実施形態の示唆および記述を本発明の範囲内に含めることができるが、これらのものは添付の図面には示していないし、または別の方法で本発明の機能を図面には示してあるが本明細書には記述していない。 Specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings. These embodiments are illustrative and are not intended to limit the scope of the invention. Suggestions and descriptions of other embodiments may be included within the scope of the present invention, but these are not shown in the accompanying drawings, or the function of the present invention is otherwise shown in the drawings. Is not described herein.

図５は、本発明の典型的な実施形態の要素の概観である。この実施形態は、ＢＬＯＢレコード５１、５３と、スパン・リスト５８と、クラスタ５２、５４、５６と、サブブロック・インデックス５０とを含む。図３８は、典型的なコンピュータ・ハードウェア上でのこれらの要素の配置を示す。すべてのデータ構造はディスク３８０上に常駐している。インデックス３８１も、いくつかのＢＬＯＢレコード３８２およびクラスタ３８３のいくつかの作業コピーを格納しているいくつかのキャッシュと一緒にメモリ内に保持されている。
６．１ハッシュ関数の概観
すべての実施形態においてはハッシュ関数を使用していないが、ハッシュ関数は、多くの実施形態でいくつかの利点を提供する。下記の説明は、本発明の種々の実施形態に関連して使用することができる例示としてのハッシュ関数の概観である。 FIG. 5 is an overview of the elements of an exemplary embodiment of the present invention. This embodiment includes BLOB records 51, 53, span list 58, clusters 52, 54, 56, and subblock index 50. FIG. 38 shows the placement of these elements on typical computer hardware. All data structures reside on disk 380. Index 381 is also maintained in memory along with several caches storing several BLOB records 382 and several working copies of cluster 383.
6.1 Overview of Hash Functions Although all embodiments do not use hash functions, hash functions provide several advantages in many embodiments. The following description is an overview of an exemplary hash function that can be used in connection with various embodiments of the invention.

ハッシュ関数は、ビットの可変長入力ブロックを受け入れ、入力ブロックをベースとするビットの出力ブロックを生成する。大部分のハッシュ関数は、出力ブロックが特定の長さ（例えば、１６ビット）になることを保証し、入力ブロックの無限集合と出力ブロックの有限集合との間でランダムではあるが、決定論的マッピングを提供するようにする。ランダムさの特性により、「ハッシュ」と呼ばれるこれらの出力を、入力ブロックの容易に操作した表示として動作させることができる。 The hash function accepts a variable length input block of bits and generates an output block of bits based on the input block. Most hash functions guarantee that the output block will be a certain length (eg, 16 bits) and are random but deterministic between an infinite set of input blocks and a finite set of output blocks Provide a mapping. Due to the nature of randomness, these outputs, called “hash”, can be operated as an easily manipulated display of the input block.

ハッシュ関数は少なくとも４つのクラスの強度を有する。 The hash function has at least four classes of strength.

狭いハッシュ関数：狭いハッシュ関数は、最も弱いクラスのハッシュ関数であり、出力値の全スペースを妥当な時間内に探索することができるような、非常に狭い（例えば、１６ビット）出力値を生成する。例えば、８ビットのハッシュ関数は、任意のデータ・ブロックを０〜２５５の範囲内のハッシュにマッピングする。１６ビットのハッシュ関数は、０〜６５５３５の範囲内のハッシュにマッピングする。特定のハッシュ値の場合には、単に探索する値が表れるまで、ランダム・ブロックを生成し、これらのブロックを狭いハッシュ関数に提供することにより、対応するブロックを発見することができる。狭いハッシュ関数は、一組のデータ値を少数のグループに任意に（しかし決定論的に）分類するために、通常、使用される。それ故、狭いハッシュ関数は、ハッシュ・テーブル・データ構造を構成し、ノイズの多い通信チャネルを通して送信したデータのエラーを検出するのに役に立つ。このクラスの例としては、ＣＲＣ−１６、ＣＲＣ−３２、フレッチャ・チェックサム、ＩＰチェックサム等がある。 Narrow hash functions: Narrow hash functions are the weakest class of hash functions, producing very narrow (eg, 16-bit) output values that can search the entire space of output values in a reasonable amount of time. To do. For example, an 8-bit hash function maps an arbitrary data block to a hash in the range 0-255. A 16-bit hash function maps to a hash in the range 0-65535. In the case of a particular hash value, the corresponding block can be found by simply generating random blocks and providing these blocks to a narrow hash function until the value to search for appears. Narrow hash functions are typically used to arbitrarily (but deterministically) classify a set of data values into a small number of groups. Therefore, a narrow hash function is useful for constructing a hash table data structure and detecting errors in data transmitted over a noisy communication channel. Examples of this class include CRC-16, CRC-32, Fletcher checksum, IP checksum and the like.

広いハッシュ関数：広いハッシュ関数は、その出力値がかなり広いということを除けば、狭いハッシュ関数に類似している。ある点においては、この定量的違いは、定性的違いを意味する。広いハッシュ関数の場合には、出力値が非常に広い（例えば、１２８ビット）ので、同じハッシュ値を有する任意の２つのランダムに選択したブロックの確率は無視することができる（例えば、１０^３８のうちの約１）。この特性により、これらの広いハッシュを、これらが計算されたデータのブロックの「ＩＤ（ｉｄｅｎｔｉｔｙ）」として使用することができる。例えば、エンティティＥ１がデータのブロックを有し、エンティティＥ２にブロックの広いハッシュを送った場合で、エンティティＥ２が同じハッシュを有するブロックを有している場合には、ブロックが実際に異なる先験的確率は無視することができる。唯一の問題は、広いハッシュ関数が非反転できるように設計されていないことである。それ故、（例えば）２^１２８値のスペースは、狭いハッシュ関数のところで説明した方法で探索するにはあまりに広すぎるが、ハッシュ関数を分析し、特定のハッシュに対応するブロックを計算するのは容易である。それ故、Ｅ１が本当に異なるブロックである場合には、Ｅ１は、Ｅ２がＥ１が１つのブロックを有すると思い込ませることができる。このクラスの例としては、任意の１２８ビットのＣＲＣアルゴリズムがある。 Wide hash function: A wide hash function is similar to a narrow hash function, except that its output value is fairly wide. In some respects, this quantitative difference means a qualitative difference. For a wide hash function, the output value is very wide (eg, 128 bits), so the probability of any two randomly selected blocks having the same hash value can be ignored (eg, 10 ³⁸ About 1) This property allows these wide hashes to be used as the “ID (identity)” of the block of data for which they were calculated. For example, if entity E1 has a block of data and has sent a wide hash of the block to entity E2 and entity E2 has a block with the same hash, the blocks are actually different a priori Probability can be ignored. The only problem is that the wide hash function is not designed to be non-invertible. Therefore, a space of (for example) 2 ¹²⁸ values is too wide to search in the way described for narrow hash functions, but it is easy to analyze the hash function and calculate the block corresponding to a particular hash It is. Therefore, if E1 is a really different block, E1 can make E2 assume that E1 has one block. An example of this class is an arbitrary 128-bit CRC algorithm.

弱一方向ハッシュ関数：弱一方向ハッシュ関数は、「ＩＤ」を提供するのに十分広いばかりでなく、特定のハッシュ値が与えられた場合、そのハッシュ値に対応するブロックを発見するのが極度に難しい暗号保証を提供する。このクラスの例としては、６４ビットＤＥＳハッシュがある。 Weak one-way hash function: A weak one-way hash function is not only wide enough to provide an “ID”, but given a particular hash value, it is extremely hard to find the block corresponding to that hash value Provide difficult cryptographic guarantees. An example of this class is a 64-bit DES hash.

強一方向ハッシュ関数：強一方向ハッシュ関数は、同じハッシュ値を有する任意の２つの異なるブロックを発見するのが難しい暗号保証を提供する追加特性を有することを除けば、弱一方向ハッシュ関数と同じものである。この場合、ハッシュ値は指定されない。このクラスの例としては、ＭＤ５およびＳＨＡ−１がある。 Strong one-way hash function: A strong one-way hash function is a weak one-way hash function, except that it has the additional property of providing cryptographic guarantees that are difficult to find any two different blocks having the same hash value. The same thing. In this case, no hash value is specified. Examples of this class are MD5 and SHA-1.

これら４つのクラスのハッシュは、選択が行われるある範囲のハッシュ強度を提供する。予想されるように、ハッシュ関数の速度は、強度が増大するにつれて低減し、トレードオフを提供し、異なる用途の場合には異なる強度が適切な強度になる。しかし、違いは非常に小さいので、最もタイムクリティカルな用途以外では、強一方向ハッシュ関数を使用することができる。 These four classes of hashes provide a range of hash strengths from which selections can be made. As expected, the speed of the hash function decreases as the strength increases, providing a trade-off, with different strengths being the appropriate strength for different applications. However, the difference is so small that a strong one-way hash function can be used except for the most time critical applications.

暗号ハッシュという用語は、多くの場合、弱一方向ハッシュ関数のクラスおよび強一方向ハッシュ関数のクラス両方を含む暗号強度を提供するハッシュを指すために使用される。 The term cryptographic hash is often used to refer to a hash that provides cryptographic strength that includes both a class of weak one-way hash functions and a class of strong one-way hash functions.

本発明の例示的実施形態は、少なくとも２つの役割でハッシュ関数を使用することができる。 Exemplary embodiments of the present invention can use hash functions in at least two roles.

１．サブブロック境界を決定するために。 1. To determine sub-block boundaries.

２．サブブロックＩＤを生成するために。 2. To generate a sub-block ID.

用途に従って、上記４つのクラスのうちの任意のクラスからのハッシュ関数をいずれかの役割で使用することができる。しかし、サブブロック境界の決定にはＩＤおよび暗号強度が必要ないので、最も弱いクラス以外からのクラスからのハッシュ関数を使用するのは非効率である。同様に、ＩＤの必要性、絶えず存在する破壊行為の脅威、および強一方向ハッシュ関数（弱一方向ハッシュ関数と比較した場合）に対する低性能というペナルティは、強一方向ハッシュ関数より弱いいかなるものもサブブロックＩＤの計算に使用すべきではないことを示唆している。 Depending on the application, hash functions from any of the four classes can be used in any role. However, since the ID and encryption strength are not required for determining the sub-block boundary, it is inefficient to use a hash function from a class other than the weakest class. Similarly, the penalty of low performance against the need for ID, the threat of vandalism that exists constantly, and strong one-way hash functions (as compared to weak one-way hash functions) is anything weaker than strong one-way hash functions. This suggests that it should not be used to calculate sub-block IDs.

ＩＤを生成するために強一方向ハッシュ関数以下の何かを使用する際につきもののセキュリティの危険は、任意のこのような弱ハッシュ関数を使用する本発明を組み込む記憶システムを考慮することにより説明することができる。このようなシステムにおいては、侵入者は、修正したサブブロックが、ターゲット・システム内にすでに存在することを侵入者が知っている他のサブブロックと同じハッシュを有するように、（ターゲット・システムにより操作される）サブブロックを修正することができる。そうすると、ターゲット・システムがそれを新しいものと置き換えないで、既存のサブブロックを保持する結果になる恐れがある。（例えば）ターゲット・システムがネットワーク上で検索したセキュリティ・パッチを正しく適用するのを防止するために、このような弱点を使用することができる。 The security risks associated with using something less than a strong one-way hash function to generate an ID are explained by considering a storage system incorporating the present invention that uses any such weak hash function. be able to. In such a system, the intruder has the same hash as the other subblocks that the intruder knows that the modified subblock already exists in the target system (by the target system). The sub-block that is operated on can be modified. Doing so can result in the target system not retaining it with a new one but retaining the existing sub-block. Such weaknesses can be used to prevent (for example) the target system from correctly applying security patches retrieved on the network.

それ故、敵意を持つ人間に曝されないシステムでサブブロックを計算するのに、広いハッシュ関数を安全に使用することができるが、弱一方向ハッシュ関数が、これらのシステムでは非セキュアとなる恐れがある。 Therefore, a wide hash function can be used safely to compute sub-blocks in systems that are not exposed to hostile humans, but weak one-way hash functions can be insecure on these systems. is there.

ここで、ブロックまたはサブブロックのハッシュを実際に使用することができる方法について説明する。
６．２暗号ハッシュの使用
暗号ハッシュ（およびここでは強一方向ハッシュ関数）の理論特性は、特に興味のある実際の特性を生成する。このようなハッシュはかなり広いので、２つのランダムに選択したサブブロックが、同じハッシュを有する確率は事実上ゼロであり（１２８ビット・ハッシュの場合には、１０^３８のうちの約１であり）、同じハッシュを有する２つのサブブロックを発見するのは計算上不可能であるので、スパイがそのようなことを行うことができないことを事実上保証している。これらの特性の密接な関係は、実際の見地から見ると、特定の暗号ハッシュ・アルゴリズムに対するハッシュ値の有限集合は、有限の可変長サブブロックの無限集合に対して１対１の関係になる。これは、同じ値にハッシュする２つのサブブロックを発見するのは実際上不可能であるので、実際には、理論上不可能な特性であることは明らかである。 Here, a method that can actually use a hash of a block or sub-block will be described.
6.2 Use of cryptographic hashes The theoretical properties of cryptographic hashes (and strong one-way hash functions here) generate actual properties that are of particular interest. Since such hashes are quite wide, the probability that two randomly selected sub-blocks have the same hash is virtually zero (in the case of a 128-bit hash, it is about 1 out of 10 ³⁸ ). Since it is computationally impossible to find two sub-blocks with the same hash, it virtually guarantees that the spy cannot do that. The close relationship between these properties, from a practical standpoint, is a one-to-one relationship between a finite set of hash values for a particular cryptographic hash algorithm and an infinite set of finite variable length sub-blocks. Obviously, this is a theoretically impossible property since it is practically impossible to find two sub-blocks that hash to the same value.

この特性は、（同一であることのために）比較の目的で、計算されたサブブロックの代わりに、暗号ハッシュを安全に使用することができることを意味する。大部分の暗号ハッシュは約１２８ビットの長さしかないので、ハッシュは、サブブロック自身のコンテンツを直接比較しなくても、サブブロックを比較するための非常に効率的な方法を提供する。 This property means that the cryptographic hash can be used safely instead of the computed sub-block for comparison purposes (because it is identical). Since most cryptographic hashes are only about 128 bits long, hashes provide a very efficient way to compare sub-blocks without directly comparing the contents of the sub-blocks themselves.

本発明の例示的実施形態で暗号ハッシュが使用されるいくつかの方法は下記の通りである。 Some ways in which cryptographic hashes are used in an exemplary embodiment of the invention are as follows.

サブブロックの比較：暗号ハッシュＨは、２つのサブブロックＡ、Ｂのコンテンツを比較しなくても、またはアクセスしなくても、２つのサブブロックＡ、Ｂを比較２８０するために使用することができる（図２８）。 Subblock comparison: Cryptographic hash H may be used to compare 280 two subblocks A, B without comparing or accessing the contents of the two subblocks A, B Yes (FIG. 28).

サブブロックのインデックス：サブブロックＡ、Ｂ、Ｃ、Ｄの集合体を索引するために、そのキーがサブブロック２９２、２９４、２９６、２９８のハッシュであるインデックス２９０を構成することができる（図２９）。
ＢＬＯＢチェック：ＢＬＯＢ３００のサブブロック３０２への分割、および再構成したＢＬＯＢ３０４へのサブブロックの以降の再組立を確実にエラーのないものにするために、暗号ハッシュを使用することができる。このことは、元のＢＬＯＢのハッシュ３０６を再構成したＢＬＯＢのハッシュ３０８と比較３０９することにより行うことができる（図３０）。
６．３安全ネットとしてのハッシュの使用
本発明の実施形態は、これらの実施形態を組み込む記憶システムをさらに複雑にする場合がある。このように複雑になると、潜在的にエラーが検出されない機会が多くなる。 Sub-block index: To index a collection of sub-blocks A, B, C, D, an index 290 whose key is a hash of sub-blocks 292, 294, 296, 298 can be constructed (FIG. 29). ).
BLOB check: A cryptographic hash can be used to ensure error-free partitioning of BLOB 300 into sub-blocks 302 and subsequent reassembly of sub-blocks into reconstructed BLOB 304. This can be done by comparing 309 the original BLOB hash 306 with the reconstructed BLOB hash 308 (FIG. 30).
6.3 Use of Hash as a Secure Net Embodiments of the present invention may further complicate storage systems that incorporate these embodiments. This complexity increases the chances of potentially no error being detected.

複雑さの主な機構は、ＢＬＯＢのサブブロックへの分割であり、このようなサブブロックの以降の再組立である。ＢＬＯＢをサブブロックに分割することにより、記憶システムが、サブブロックを間違って追加したり、削除したり、再配置したり、置換したり、複製したり、または何らかの他の方法で偶然のエラーのより大きなリスクに曝されたりする恐れがでてくる。 The main mechanism of complexity is the division of the BLOB into sub-blocks and the subsequent reassembly of such sub-blocks. By splitting the BLOB into sub-blocks, the storage system may accidentally add, delete, relocate, replace, duplicate, or some other way of accidental errors. There is a risk of exposure to greater risks.

このリスクは、サブブロックに分割される前にＢＬＯＢのハッシュ（好適には暗号ハッシュであることが好ましい）を計算し、このハッシュを全体としてＢＬＯＢに関連するエンティティと一緒に格納し、次に、格納しているハッシュを、再構成したブロックの計算したハッシュと比較することにより、低減または除去することができる。このようなチェックは、本発明を使用することによるエラーが検出されないリスクを事実上取り除く非常に強力な安全ネットを提供する（図３０）。 This risk calculates a hash of the BLOB (preferably a cryptographic hash) before it is divided into sub-blocks, stores this hash together with the entity associated with the BLOB, and then By comparing the stored hash with the calculated hash of the reconstructed block, it can be reduced or eliminated. Such a check provides a very strong safety net that virtually eliminates the risk that no errors are detected by using the present invention (FIG. 30).

ＢＬＯＢをチェックするもう１つの方法は、そのサブブロックのハッシュの連結をハッシュし、記憶装置からＢＬＯＢを検索した場合の値をチェックする方法である。この方法は、全体的に見てハッシュしなければならないデータが少なくてすみ、このような実施形態をより効率的にすることができるという利点を有する。
６．４クラスタ内へのサブブロックの格納
クラスタ内にサブブロックを格納することができる方法は多数ある。「サブブロックのコンテンツ」という用語は、実際のサブブロックを形成するバイトのシーケンスを意味する。例示的実施形態においては、クラスタ７４内のサブブロック７２は、メタデータの介入なしで背中合わせに格納される（図７）。クラスタがそれ自身のディレクトリを持たない実施形態の場合には、背中合わせのサブブロック・コンテンツは、クラスタが含んでいなければならないすべてのものであってもよい。 Another method for checking the BLOB is to hash the concatenation of the sub-block hashes and check the value when the BLOB is retrieved from the storage device. This method has the advantage that less overall data has to be hashed and such an embodiment can be made more efficient.
6.4 Storing sub-blocks in a cluster There are many ways that a sub-block can be stored in a cluster. The term “sub-block content” means a sequence of bytes that form an actual sub-block. In the exemplary embodiment, sub-blocks 72 in cluster 74 are stored back to back without metadata intervention (FIG. 7). In embodiments where the cluster does not have its own directory, the back-to-back sub-block content may be everything that the cluster must contain.

背中合わせにサブブロックを格納する利点は、サブブロックの隣接する一続きの部分を１つのシーケンシャルな動作としてクラスタから読み出すことができることであり、次に、最初に、メタデータを除去しなくても、メモリ内に保持し、１つのシーケンシャルな動作として書き出すことができることである。 The advantage of storing sub-blocks back-to-back is that adjacent runs of sub-blocks can be read from the cluster as a sequential operation, and then without first removing the metadata, It can be held in memory and written out as a single sequential operation.

サブブロックをクラスタに分割する方法を決定するために多数の方法を使用することができる。１つの方法は、少なくともＳ個のサブブロックを有するまでクラスタにサブブロックを書き込む方法である。ここで、Ｓは所定の定数である。もう１つの方法は、少なくともＭメガバイトを含むまで、クラスタにサブブロックを書き込む方法である。ここで、Ｍは所定の定数である。
６．５クラスタ・サブブロック・ディレクトリ
クラスタは、クラスタ内のサブブロックについての情報を提供し、クラスタ内のサブブロックの位置を迅速に発見することができるサブブロック・ディレクトリを有することができる。 A number of methods can be used to determine how to divide a sub-block into clusters. One method is to write the sub-block to the cluster until it has at least S sub-blocks. Here, S is a predetermined constant. Another method is to write sub-blocks to the cluster until it contains at least M megabytes. Here, M is a predetermined constant.
6.5 Cluster Subblock Directory A cluster can have a subblock directory that provides information about the subblocks in the cluster and can quickly locate the subblocks in the cluster.

クラスタは、ディレクトリ７０を有している場合には、ディレクトリをクラスタの始めの部分（図７）またはクラスタの終わりの部分に置くことができる。もう１つの例は、サブブロック・コンテンツ９２とディレクトリ９０エントリをインタリーブする例である（図９）。最後に、ディレクトリ８０、８２は別々に格納することができる（図８）。 If the cluster has a directory 70, the directory can be placed at the beginning of the cluster (FIG. 7) or at the end of the cluster. Another example is an example of interleaving sub-block content 92 and directory 90 entries (FIG. 9). Finally, the directories 80 and 82 can be stored separately (FIG. 8).

１つの簡単なオプションは、クラスタ内のサブブロック数上に上部限界Ｌを置き、クラスタ内のサブブロック数が何であれ、カウントにＬディレクトリ・エントリのアレイを加えたものとしてディレクトリを表す方法である。これにより固定長ディレクトリ８０、８２が出来上がり、クラスタのディレクトリを、残りのクラスタのコンテンツ８４、８６（すなわち、サブブロックのコンテンツ）とは別々に１つのアレイを格納することができる（図８）。
６．６クラスタ・サブブロック・ディレクトリ内のサブブロック・メタデータ
クラスタのサブブロック・ディレクトリは、各サブブロックの長さを格納することができる。通常、各サブブロックの長さの単位はバイトである。サブブロックの長さを格納した場合には、クラスタのサブブロックのコンテンツを、境界がサブブロック間にあることを決定するために、分割方法を呼び出さなくても、サブブロックに分割することができる。 One simple option is to place the upper limit L on the number of subblocks in the cluster and represent the directory as a count plus an array of L directory entries, whatever the number of subblocks in the cluster. . As a result, fixed-length directories 80 and 82 are created, and the cluster directory can be stored in one array separately from the remaining cluster contents 84 and 86 (that is, sub-block contents) (FIG. 8).
6.6 Subblock Metadata in Cluster Subblock Directory The cluster subblock directory can store the length of each subblock. Usually, the unit of length of each sub-block is byte. If the length of the sub-block is stored, the contents of the sub-block of the cluster can be divided into sub-blocks without invoking the division method to determine that the boundary is between the sub-blocks .

クラスタのディレクトリは、各サブブロックのハッシュを格納することができる。例えば、ディレクトリは、クラスタ内の各サブブロックの１２８ビットのＭＤ５または１６０ビットのＳＨＡ−１を格納することができる。各サブブロックのハッシュを格納することは役に立つ。何故なら、格納中、システムが、サブブロックＸのコンテンツをサブブロックＹのコンテンツと比較しなくても、新しく到着したサブブロックＹがクラスタ内で発見されたことを確認することができるからである。代わりに、システムは、サブブロックＹのハッシュを計算し、それを（そのクラスタのディレクトリ内で発見することができる）サブブロックＸのハッシュと比較する。それ故、格納しているＢＬＯＢ内のサブブロックを、記憶装置内のサブブロックのコンテンツを読み出さなくても、インデックスおよびクラスタ・ディレクトリだけを使用して、記憶装置内に存在しているか否かを試験することができる。 The cluster directory can store a hash of each sub-block. For example, the directory can store 128-bit MD5 or 160-bit SHA-1 for each sub-block in the cluster. It is useful to store a hash of each subblock. This is because during storage, the system can verify that a newly arrived sub-block Y has been found in the cluster without having to compare the content of sub-block X with the content of sub-block Y. . Instead, the system computes a hash of sub-block Y and compares it to the hash of sub-block X (which can be found in the cluster's directory). Therefore, whether or not a sub-block in the stored BLOB exists in the storage device using only the index and the cluster directory without reading the contents of the sub-block in the storage device. Can be tested.

また、クラスタのディレクトリは、各サブブロックに対するサブブロック識別子を格納することもできる。サブブロックの識別子は、クラスタ内の一組のサブブロック内で一意のものである。サブブロック識別子を実施する１つの簡単な方法は、固定幅（例えば、１６ビット）を選択し、各クラスタ内の一連番号カウンタを割り当て、ゼロから開始し、次の整数を各サブブロックにその一連番号識別子として割り当てる方法である。カウンタが最大値に達した場合には、クラスタを新データに対して単に閉鎖することができる。別の方法としては、サブブロックをクラスタから削除した場合には、未使用の識別子を再度割り当てることができる。これはサブブロック識別子を実施する多くの方法のうちの１つの方法である。 The cluster directory can also store a sub-block identifier for each sub-block. The sub-block identifier is unique within a set of sub-blocks within the cluster. One simple way to implement a sub-block identifier is to select a fixed width (eg, 16 bits), assign a sequence number counter in each cluster, start at zero, and set the next integer to each sub-block in its sequence. This is a method of assigning as a number identifier. If the counter reaches the maximum value, the cluster can simply be closed for new data. Alternatively, when a sub-block is deleted from the cluster, an unused identifier can be reassigned. This is one of many ways to implement the sub-block identifier.

一連番号をサブブロック識別子として使用した場合には、その連続性をＢＬＯＢ内のサブブロックの１つの一続きの部分から格納したクラスタ内のサブブロック２７６〜２７８の一続きの部分の始まりおよび終わりを示すために使用することができる。ある実施形態の場合には、このことは各格納している一続きの部分２７２、２７４の終わりのところの一連番号をスキップ（廃棄）することにより行うことができる（図２７）。一連番号を使用しない場合には、クラスタ内のサブブロックの一続きの部分の（元のＢＬＯＢ内のサブブロックの一続きの部分に対する）終わりを示すために、各サブブロックのメタデータに、ブール値を追加することができる。
６．７クラスタの圧縮
システム内に圧縮（例えば、制限なしに、ＧＺｉＰ）を組み込むことができる方法は多数ある。１つの簡単な方法は、ディスクに書き込む前に、各クラスタに対して１つのシーケンシャルな動作として圧縮を行う方法である。もう１つの方法は、各サブブロックを個々に圧縮する方法である。もう１つの方法は、隣接する一連番号と一緒にサブブロックの各一続きの部分を圧縮する方法である。 If a sequence number is used as a subblock identifier, the beginning and end of a sequence of subblocks 276-278 in the cluster that stores its continuity from one sequence of subblocks in the BLOB. Can be used to show. In one embodiment, this can be done by skipping (discarding) the sequence number at the end of each stored sequence 272, 274 (FIG. 27). If a sequence number is not used, each subblock's metadata will contain a Boolean to indicate the end of the sequence of subblocks in the cluster (relative to the sequence of subblocks in the original BLOB). A value can be added.
6.7 Cluster Compression There are many ways in which compression (eg, without limitation, GZiP) can be incorporated into the system. One simple method is to compress each cluster as one sequential operation before writing to disk. Another method is to compress each sub-block individually. Another method is to compress each stretch of sub-block along with adjacent sequence numbers.

クラスタは、圧縮した形式でディスク上に格納することができる。また、これらのクラスタは、圧縮した形式でメモリに格納することもできる。
６．８スパン・サブブロック−一続きの部分の識別
各スパンは、特定のクラスタ内のサブブロックの一続きの部分を識別する。例示的実施形態の場合には、スパンは、サブブロックの一続きの部分を含むクラスタを識別する情報を含む。サブブロックの一続きの部分を識別するための広い範囲の可能性がある。そのため、一続きの部分内の最初および最後のサブブロックを識別することができ、または最初（または最後）のサブブロックを識別することができ、長さを提供することができる。長さはバイト単位またはサブブロック単位で測定することができる。 Clusters can be stored on disk in a compressed format. These clusters can also be stored in memory in a compressed format.
6.8 Span sub-block—identification of a series of parts Each span identifies a series of parts of a sub-block within a particular cluster. In the exemplary embodiment, the span includes information identifying a cluster that includes a stretch of sub-blocks. There is a wide range of possibilities for identifying a stretch of sub-blocks. As such, the first and last sub-blocks within a stretch can be identified, or the first (or last) sub-block can be identified and a length can be provided. The length can be measured in bytes or subblocks.

例示的実施形態のサブブロックを識別するために、スパンは、サブブロックのハッシュ（この場合、クラスタは（サブブロックのディレクトリを使用して（１つ有している場合））サブブロックを探索しなければならないが）、クラスタ（例えば、「第３のサブブロック」）内のサブブロックの位置、またはサブブロック識別子を使用することができる。 To identify the sub-block in the exemplary embodiment, the span is a hash of the sub-block (in this case, the cluster searches for the sub-block (if it has one (if it has one)). The location of the sub-block within the cluster (eg, “third sub-block”), or the sub-block identifier may be used.

ハッシュの幅は比較的広い。クラスタ内に（例えば）１０００のサブブロックが存在する場合には、サブブロック識別子は、約１０ビットの幅を有していればよいのだが、典型的なハッシュは１２８ビットの幅を有する。そのクラスタ内の（サブブロック単位で測定した）位置を使用すると、スペースをもっと効率的に使用することができるが、（サブブロックを含んでいるＢＬＯＢを記憶装置から削除した場合に起こるかもしれないように）サブブロックをクラスタから削除した場合、故障が起こる。これを避けるために、例示的実施形態の場合には、（クラスタ内で一意の）クラスタ内の各サブブロックに一意の識別子を割り当てることができる。この識別子は、クラスタのディレクトリ内に各サブブロックのメタデータと一緒に格納することができる。このような識別子は、（ビット単位で）十分狭いものであってもよいが、サブブロックがクラスタ内でシフトしても、サブブロックをはっきりと識別する。 The width of the hash is relatively wide. If there are (for example) 1000 sub-blocks in the cluster, the sub-block identifier need only have a width of about 10 bits, but a typical hash has a width of 128 bits. Using locations (measured in subblocks) within the cluster can use space more efficiently, but may occur if the BLOB containing the subblock is deleted from storage If a sub-block is deleted from the cluster, a failure will occur. To avoid this, in the exemplary embodiment, a unique identifier can be assigned to each sub-block in the cluster (unique within the cluster). This identifier can be stored in the cluster directory along with the metadata for each sub-block. Such an identifier may be sufficiently narrow (in bits) but clearly identifies the sub-block even if the sub-block shifts within the cluster.

もう１つのアプローチは、そのハッシュでサブブロックを参照する方法であるが、同じクラスタ内で他のすべてのサブブロックからそのサブブロックを区別するために必要なものである。スパン・レコード内の短い固定長フィールドは、記録するハッシュのバイト数を記録するために使用することができる。この方法を使用すれば、サブブロック識別子を使用する必要がなくなるし、スパン・レコードに長いハッシュによる負担がかからなくなる。この方法を使用すれば、スパン・レコードは可変長を有することができる。この方法の１つの潜在的な問題は、クラスタに追加されるサブブロックが、既存の参照を曖昧にする恐れがあることである。この問題は、このような曖昧な参照がいつでも曖昧な参照を満たす第１のサブブロックを参照するように注意することにより解決することができる。 Another approach is to reference a subblock by its hash, but is necessary to distinguish that subblock from all other subblocks in the same cluster. A short fixed length field in the spanned record can be used to record the number of bytes of hash to record. By using this method, it is not necessary to use a sub-block identifier, and the span record is not burdened by a long hash. Using this method, spanned records can have variable length. One potential problem with this method is that subblocks added to the cluster can obscure existing references. This problem can be solved by taking care that such an ambiguous reference always refers to the first sub-block that satisfies the ambiguous reference.

もう１つの方法は、サブブロックの一連番号を使用するが、これらの一連番号をスパンにより直接参照されるサブブロックだけに割り当てる方法である。実際には、スパンの第１のサブブロックは非常に少ないので、遥かに少ない数の一連番号を格納するだけですむ。
６．９部分サブブロックの一致
ＢＬＯＢ１７０の格納中、１つまたは複数の一致するサブブロックＢ、Ｃの一続きの部分をクラスタ１７４内で発見した場合には、一致しているサブブロックの一続きの部分のどちらかの側面上の一致していないサブブロックのある部分が、格納しているＢＬＯＢ内の対応するサブブロックの対応部分と一致する可能性がある。図１７は、格納中のＢＬＯＢ１７０および比較しているクラスタ１７４を示す。インデックスを使用して、サブブロックＢＣの一致する一続きの部分を発見した。各側面上のサブブロックは一致しない。ＡはＥと一致しないし、ＤはＦと一致しない。それ故、一致する一続きの部分はちょうど２つのサブブロックの長さである。しかし、ＢＣの一致を発見した場合、周囲のサブブロックをもっと精密なレベルで比較することができる。 Another method is to use subblock sequence numbers, but assign these sequence numbers only to subblocks that are directly referenced by the span. In practice, the first sub-block of the span is so small that only a much smaller number of sequence numbers need to be stored.
6.9 Partial Subblock Matching When storing BLOB 170, if a succession of one or more matching subblocks B, C is found in cluster 174, a sequence of matching subblocks Some parts of non-matching sub-blocks on either side of the part may match the corresponding part of the corresponding sub-block in the stored BLOB. FIG. 17 shows the BLOB 170 being stored and the cluster 174 being compared. Using the index, a contiguous stretch of sub-block BC was found. The sub-blocks on each side do not match. A does not match E, and D does not match F. Therefore, the contiguous stretch is exactly two subblocks long. However, if a BC match is found, the surrounding sub-blocks can be compared at a more precise level.

サブブロックＡの終わりとサブブロックＥの終わりと比較すれば、これらのサブブロックが、同じ（例えば）１２３バイトの接尾部を共有していることが分かる。同様に、サブブロックＤの始まりをサブブロックＦの始まりと比較すると、これらのサブブロックが、同じ（例えば）１０４５バイトの接頭部を共有していることが分かる。これらを部分サブブロックの一致と呼ぶ。 Comparing the end of sub-block A with the end of sub-block E, it can be seen that these sub-blocks share the same (for example) 123 byte suffix. Similarly, comparing the start of sub-block D with the start of sub-block F, it can be seen that these sub-blocks share the same (for example) 1045 byte prefix. These are called partial sub-block matches.

部分サブブロックの一致を発見した場合には、多数の方法を使用することができる。図１８は、スパン内の最初のサブブロックの始まりのところ、およびスパン内の最後のサブブロックの終わりのところで無視すべきバイト数を記録する余分なフィールド「開始スキップ」１８０および「終了スキップ」１８２を含むように、スパン・レコード構造を増大することができる方法を示す。もう１つの方法は、サブブロックのどちらかの終わりを延長するために、バイト数を記録する２つのフィールド「開始エクステンド」および「終了エクステンド」を使用する方法である。ある実施形態は、上記各フィールドの一方または両方の使用を選択することができる。 If a partial subblock match is found, a number of methods can be used. FIG. 18 illustrates the extra fields “Start Skip” 180 and “End Skip” 182 that record the number of bytes to be ignored at the beginning of the first subblock in the span and at the end of the last subblock in the span. We show how the spanned record structure can be increased to include Another method is to use two fields “Start Extend” and “End Extend” to record the number of bytes to extend either end of the sub-block. Some embodiments may choose to use one or both of the above fields.

サブブロックの一続きの部分内のバイトのある範囲を参照するもう１つの方法は、「終了スキップ」フィールドを、スパン内のバイトの全数である長さで置換する方法である。
６．１０フラグメンテーションの低減
格納しているＢＬＯＢがすでに格納済みの多くのサブブロックを含んでいるが、多くの異なるクラスタ全体に散乱している場合には、ＢＬＯＢは、ディスク全体を指すスパンのリストの表示で終わる。要するに多数に分割される。 Another way to refer to a range of bytes in a stretch of sub-blocks is to replace the “end skip” field with a length that is the total number of bytes in the span.
6.10 Reduced Fragmentation When a stored BLOB contains many stored sub-blocks but is scattered across many different clusters, the BLOB is a list of spans that point to the entire disk. Ends with the display. In short, it is divided into a large number.

一致しないサブブロックの長い一続きの部分内の１つのサブブロックが一致する場合には、ある特に不都合な形のフラグメンテーションが起こる。図１９は、ＢＬＯＢ１１９０が記憶装置内にすでに格納されていて、ＢＬＯＢ２１９２を格納中であり、１つの一致するサブブロックＣが、ＢＬＯＢ２内のサブブロックＦ〜Ｍの他の方法で一致しない一続きの部分内に位置するこの一例を示す。結果としては、一致するサブブロックに対する１つのスパン・レコード１９４がスパン・リスト１９６内に生成される。このタイプのフラグメンテーションは、ＢＬＯＢ２の検索時間を長くする傾向がある。何故なら、ランダム・ディスク・アクセスを、第１のクラスタ１９８および第２のクラスタ１９９に対して行わなければならないからである。 One particularly inconvenient form of fragmentation occurs when one subblock in a long stretch of non-matching subblocks matches. FIG. 19 shows that BLOB1 190 is already stored in the storage device, BLOB2 192 is being stored, and one matching sub-block C does not match in other ways of sub-blocks F-M in BLOB2. An example of being located in a continuation part is shown. As a result, one span record 194 for the matching sub-block is generated in the span list 196. This type of fragmentation tends to increase the search time for BLOB2. This is because random disk access must be made to the first cluster 198 and the second cluster 199.

ある種の実施形態は、孤立している一致サブブロックを一致していないとして処理し、これらのサブブロックを次に格納することにより、このタイプの１つの一致サブブロック・フラグメンテーションを避けることができる。図２０は、余分のスペースを使用するが、ＢＬＯＢ２２０２のフラグメンテーションを低減することにより、サブブロックＣの孤立している一致を格納させるのを無視する方法を示す。この方法は、一致するサブブロックの予め定義したしきい値Ｔより短いすべての一致する一続きの部分を無視することにより一般化することができる。ある実施形態の場合には、１より大きいＴの任意の値はフラグメンテーションを低減する傾向がある。値２も役に立つ。
６．１１ＢＬＯＢテーブル
ＢＬＯＢを格納する記憶システムは、そのユーザがＢＬＯＢを検索することができるように、ＢＬＯＢを参照することができるようにするある方法を提供するものでなければならない。 Certain embodiments can avoid this type of one matching sub-block fragmentation by treating isolated matching sub-blocks as not matching and storing these sub-blocks next. . FIG. 20 illustrates a method that uses extra space but ignores storing an isolated match of sub-block C by reducing the fragmentation of BLOB2 202. This method can be generalized by ignoring all matching sequences that are shorter than the predefined threshold T of matching sub-blocks. In some embodiments, any value of T greater than 1 tends to reduce fragmentation. A value of 2 is also useful.
6.11 BLOB Table The storage system that stores the BLOB must provide some way to allow the user to browse the BLOB so that the user can search the BLOB.

１つの方法は、ＢＬＯＢのハッシュ１１０を識別子として使用する方法である（図１１）。それ故、ユーザは、ＢＬＯＢを記憶システムに提出し、ＢＬＯＢのハッシュ（例えば、ＭＤ５ハッシュ）を書き留める。ＢＬＯＢを検索するために、ハッシュを記憶システムに提出し、システムはＢＬＯＢを返送する。 One method is to use the BLOB hash 110 as an identifier (FIG. 11). Therefore, the user submits the BLOB to the storage system and writes down the BLOB hash (eg, MD5 hash). To retrieve the BLOB, the hash is submitted to the storage system, and the system returns the BLOB.

もう１つの方法は、任意の名前を各ＢＬＯＢに割り当てる方法である。従来のファイル・システムはこの方法を使用する。 Another method is to assign an arbitrary name to each BLOB. Traditional file systems use this method.

どんなネーミング・スキームを採用しようとも実施しなければならない。このような実行は、本質的には、ＢＬＯＢ１１２名前空間から（スパンのリスト１１６を含む（または参照する）ＢＬＯＢレコード１１４自身へのマッピングからなる（図１１）。このマッピングは、デジタル探索ツリー、Ｂツリーおよびハッシュ・テーブルのようなすべてのタイプの従来のデータ構造を使用して行うことができる。
６．１２スパンのリストおよびツリー
ＢＬＯＢテーブル１１２が参照する各ＢＬＯＢレコード１１４は、ＢＬＯＢの任意のメタデータを含み、スパン・レコード１１６の順序付きシーケンスを含んでいるかまたはポイントする（図１１）。各スパン・レコードは、クラスタ内のサブブロックの（隣接する）一続きの部分を識別する。 Whatever naming scheme is adopted, it must be implemented. Such an execution consists essentially of a mapping from the BLOB 112 namespace to the BLOB record 114 itself (which includes (or references) the list of spans 116) (FIG. 11). This can be done using all types of conventional data structures such as trees and hash tables.
6.12 List of spans and trees Each BLOB record 114 referenced by the BLOB table 112 contains any metadata for the BLOB and contains or points to an ordered sequence of span records 116 (FIG. 11). Each span record identifies a sequence of (adjacent) subblocks in the cluster.

スパンの順序付きリスト内にスパンを維持すると、全ＢＬＯＢをシーケンシャルに効率的に検索することができるが、格納しているＢＬＯＢ上でランダム・アクセス読出しを行うために線形探索（またはスパン・レコードをランダムにアクセスできる場合には、二分探索）を必要とする。ランダム・アクセス読出しをスピードアップするために、ＢＬＯＢのスパンをツリー構造に編成することができる。図２６は、３つの分岐を含むツリーの一例である（が、任意の分岐を使用することができる）。各非葉ノードは、その子ノードが表すブロックの連結であるバイトの有限個のブロックを表す。各ノードは、その子ノードが表すブロックの長さである３つの長さを含む。各葉ノードは、クラスタ内の１つまたは複数のサブブロックのシーケンスを識別するスパン２６０からなる。このようなツリーが表す格納しているＢＬＯＢのバイトＪ〜Ｋのランダム・アクセス読出しは、バイトＪ〜Ｋを含むスパンを発見するためにツリーを下方に移動し、次にクラスタからサブブロック・コンテンツ・バイトを検索することにより行うことができる。
６．１３サブブロック・インデックス
サブブロック・インデックス（図５）を使用すれば、記憶装置内のすべてのクラスタの線形探索を行わなくても、記憶装置内に特定のサブブロックがすでに存在するか否かを判定することができる。また、インデックスは、一致するサブブロックの位置を発見する際に役に立つ情報を提供することができる。 Maintaining spans in an ordered list of spans allows efficient and efficient retrieval of all BLOBs sequentially, but does a linear search (or span record for random access reads on the stored BLOB). If it can be accessed randomly, a binary search) is required. To speed up random access reads, BLOB spans can be organized in a tree structure. FIG. 26 is an example of a tree containing three branches (although any branch can be used). Each non-leaf node represents a finite block of bytes that is a concatenation of the blocks represented by its child nodes. Each node contains three lengths that are the length of the block that the child node represents. Each leaf node consists of a span 260 that identifies a sequence of one or more sub-blocks in the cluster. Random access reads of bytes B-K of the stored BLOB represented by such a tree move down the tree to find the span containing bytes J-K, and then subblock content from the cluster • Can be done by searching for bytes.
6.13 Subblock Index Using a subblock index (FIG. 5), whether or not a particular subblock already exists in the storage device without performing a linear search of all clusters in the storage device Can be determined. The index can also provide information useful in finding the location of matching sub-blocks.

インデックス５０は、それぞれがインデックス・キーをインデックス値に結合しているエントリの組織した集合体として表示することができる。エントリは、エントリ・レコード（それぞれがキー・フィールドおよび値フィールドからなる）として、インデックス内に明示的に、または（例えば、インデックスが、キー上に葉ノード内に値を含むバイナリ・デジタル探索ツリーとして組織されている場合には）暗黙的に格納することができる。 Index 50 may be displayed as an organized collection of entries, each binding an index key to an index value. An entry can be either as an entry record (each consisting of a key field and a value field), explicitly in the index, or as a binary digital search tree (eg, the index contains a value in a leaf node on the key) Can be stored implicitly (if organized).

インデックス・キーは、サブブロックのコンテンツであっても、サブブロックのコンテンツのハッシュであっても、またはサブブロックのコンテンツのハッシュの単なる一部であってもよい。サブブロックのコンテンツのハッシュの一部（例えば、全１６バイトではなく、ＭＤ５ハッシュの最初の８バイト）だけを格納すると、時に起こる衝突を犠牲にして、インデックスのサイズを小さくすることができる。２つ以上のサブブロックが同じ部分ハッシュを有している場合には、インデックスは、両方のエントリを格納し、検索することができるものでなければならない。 The index key may be the content of the sub-block, the hash of the content of the sub-block, or just a part of the hash of the content of the sub-block. Storing only a portion of the sub-block content hash (eg, the first 8 bytes of the MD5 hash, not the entire 16 bytes) can reduce the size of the index at the expense of occasional collisions. If two or more sub-blocks have the same partial hash, the index must be able to store and retrieve both entries.

インデックス値は、記憶装置内のサブブロックの位置を発見する際に役に立つ情報でなければならない。ある極端な実施形態の場合には、この値は、クラスタ番号およびクラスタ内の特定のサブブロック（例えば、識別子、サブブロック一連番号またはサブブロック・ハッシュ）を識別する情報からなる正確な参照を提供することができる。極端な他の実施形態の場合には、インデックス値をクラスタ番号だけから構成することができる。サブブロックのクラスタ番号が分かると、存在する場合には、クラスタ内のサブブロックを発見するためにクラスタ・ディレクトリを探索することができる。インデックス内のスペースをさらに制約するために、インデックス値を、探索するのに２つ以上のクラスタを必要とするクラスタ番号の一部（例えば、クラスタ番号の最後の２つのビット）だけで構成することができる。 The index value should be information useful in finding the location of the sub-block in the storage device. In some extreme embodiments, this value provides an accurate reference consisting of the cluster number and information identifying a particular sub-block within the cluster (eg, identifier, sub-block serial number or sub-block hash) can do. In extreme other embodiments, the index value can consist only of cluster numbers. Knowing the cluster number of the sub-block, if present, can search the cluster directory to find the sub-block in the cluster. To further constrain the space in the index, the index value consists only of the part of the cluster number that requires more than one cluster to search (eg the last two bits of the cluster number) Can do.

選択の優れた組合わせは、インデックス・キーをサブブロック・ハッシュの頂部の８バイトとし、インデックス値をサブブロックを含むクラスタの数とする方法である。各クラスタに対するディレクトリが存在する限り、これらの選択は、インデックスのサイズを小さいままに維持し、依然として記憶装置の任意のサブブロックに高速でアクセスすることができる。 A good combination of choices is to have the index key as the top 8 bytes of the subblock hash and the index value as the number of clusters containing the subblock. As long as there is a directory for each cluster, these choices can keep the size of the index small and still have fast access to any sub-block of storage.

インデックスは、デジタル探索ツリー、バイナリ・ツリー、およびハッシュ・テーブルを含む種々のデータ構造により行うことができる。
６．１４インデックスの格納
インデックスは、メモリ内またはディスク上に格納することができる。インデックスのサイズの低減は、インデックスがメモリ内に保持されている場合には重要な問題である。実験の結果、ある実施形態の場合には、インデックスがメモリ内に保持されている場合には、システムの動作が遥かに速くなることが分かっている。クラスタ内の目標のサブブロックの位置を識別する情報を格納しなくてすむならば、インデックスのサイズをかなり低減することができる。それ故、典型的な実施形態の場合には、インデックス内にクラスタ番号だけを格納する。
６．１５サブブロック・インデックスのためのハッシュ・テーブルの使用
サブブロック・インデックスは、低冗長記憶システムの速度を判定する際に非常に重要なものであるので、このデータ構造を最高速でアクセスできるように設計するのは重要なことである。ハッシュ・テーブルは、０（１）時間内にアクセスを提供するので、ハッシュ・テーブルは、サブブロック・インデックスに対して非常に優れたデータ構造を提供する。しかし、このハッシュ速度アクセスは、かなり高いものにつく。以下のいくつかの節は、サブブロック・インデックスが提起する課題について説明する。
６．１６ハッシュ・テーブルの衝突
この節においては、ハッシュ・テーブルの衝突について説明するが、インデックスがハッシュ・テーブルを使用して実施される場合にだけ適用される。 Indexing can be done by various data structures including digital search trees, binary trees, and hash tables.
6.14 Storing Indexes Indexes can be stored in memory or on disk. Reducing the size of the index is an important issue when the index is held in memory. Experiments have shown that in some embodiments, the system operates much faster if the index is held in memory. If it is not necessary to store information identifying the location of the target sub-block in the cluster, the size of the index can be significantly reduced. Therefore, in the exemplary embodiment, only the cluster number is stored in the index.
6.15 Use of hash table for sub-block index Sub-block index is very important in determining the speed of low-redundant storage systems, so this data structure can be accessed at the fastest speed It is important to design so that Since the hash table provides access within 0 (1) time, the hash table provides a very good data structure for the sub-block index. However, this hash rate access is quite expensive. The following sections describe the challenges posed by the subblock index.
6.16 Hash table collisions This section describes hash table collisions, but only applies if the index is implemented using a hash table.

衝突は、２つのキー２１０、２１２が、同じ位置（スロット）２１６にハッシュ２１４した場合に、ハッシュ・テーブル内で起こる（図２１）。この状況を解決する１つの方法は、第２のエントリを単に廃棄するという方法である。ある場合には、これは正しい選択である場合がある。しかし、ハッシュ・テーブルが損失を許容するものでない場合には、このオプションを使用することはできないので、この「オーバーフロー」状況を処理するために種々様々な技術のうちの１つを使用することができる。 A collision occurs in the hash table when two keys 210, 212 hash 214 to the same location (slot) 216 (FIG. 21). One way to solve this situation is to simply discard the second entry. In some cases this may be the right choice. However, if the hash table is not tolerant of loss, this option cannot be used, so one of a wide variety of techniques can be used to handle this “overflow” situation. it can.

衝突を処理するために昔から使用されてきた１つの技術は、「オーバーフロー」領域２２０と呼ぶ別の記憶領域を有する方法である。各ハッシュ・テーブル・スロットは、オーバーフロー・フィールド２２２を含む。スロット内で衝突が起きた場合には、オーバーフロー・エントリ２２４は、オーバーフロー領域内に格納され、エントリへのポインタがスロット２２２内に置かれる（図２２）。オーバーフロー領域によりエントリはまた相互にポイントすることができ２２６、各オーバーフロー・スロットは、エントリのリストをポイントすることができる（図２２）。（ハッシュ・テーブルがメモリ内に位置していて、メモリ・ヒープの形をしている場合のように）別々のオーバーフロー領域を使用できる場合には、この技術はうまく動作する。しかし、ハッシュ・テーブルがディスク上に位置している場合には、オーバーフロー領域内にオーバーフロー・エントリを置くと、通常、非常に遅い少なくとも１回のランダム・アクセス・シークを行うステップが関連してくる。 One technique that has been used for a long time to deal with collisions is to have a separate storage area called the “overflow” area 220. Each hash table slot includes an overflow field 222. If a collision occurs in the slot, the overflow entry 224 is stored in the overflow area and a pointer to the entry is placed in the slot 222 (FIG. 22). Due to the overflow area, entries can also point to each other 226, and each overflow slot can point to a list of entries (FIG. 22). This technique works well if separate overflow areas can be used (as if the hash table is located in memory and is in the form of a memory heap). However, if the hash table is located on disk, placing an overflow entry in the overflow area usually involves a very slow step of performing at least one random access seek. .

衝突へのもっとうまいアプローチは、衝突しているエントリを、ハッシュ・テーブル自身内に格納する方法である。昔からのアプローチの場合には、衝突が起こると、第２のハッシュ関数により第２の項目キーがハッシュされ、結果として得られたスロットがチェックされる。スロットが空である場合には、エントリをそこに格納することができる。もしスロットが空でない場合には、第３のハッシュ関数を呼び出すことができ、空のスロットが発見されるまでこの手順が反復して行われる。全テーブルが満杯である場合には、テーブルを分割してからでなければ、新しいエントリを追加することはできない。一般に、ハッシュ関数Ｈ（Ｋ，Ｘ）は、Ｋがハッシュするキーであり、Ｘが、衝突しているエントリに対するハッシュ・テーブル内の連続している候補の位置を発見するために増大することができる正の整数である場合に定義することができる。キーＫを探索するために、キーを含むスロットを発見するまで、または（テーブル内のハッシュ・オーバーフロー・チェーンの終わりを示す）空のスロットに遭遇するまで、Ｘ＝１，２，．．．に対してスロットＨ（Ｋ，Ｘ）がチェックされる。 A better approach to collision is to store the conflicting entries in the hash table itself. In the traditional approach, when a collision occurs, the second item key is hashed by the second hash function and the resulting slot is checked. If the slot is empty, the entry can be stored there. If the slot is not empty, a third hash function can be called and this procedure is repeated until an empty slot is found. If all tables are full, new entries cannot be added until the tables are split. In general, the hash function H (K, X) is the key that K hashes, and X can be increased to find the position of consecutive candidates in the hash table for the conflicting entry. It can be defined if it is a positive integer. To search for key K, X = 1, 2,... Until a slot containing the key is found or until an empty slot is encountered (indicating the end of the hash overflow chain in the table). . . Is checked for slot H (K, X).

このアプローチの問題は、ハッシュ・テーブルが大きなもので、ディスク上に位置している場合には、衝突チェーンの後で、非常に時間がかかる一連のランダム・アクセス・シークをディスク上で行わなければならないことである。このことはＨ（Ｋ，Ｘ）＝Ｈ（Ｋ，Ｘ−１）＋１と定義することにより、すなわち、（テーブルの終わりのところを囲んでいる）次の隣接スロット２３０（図２３）に溢れることにより避けることができる。この技術の場合には、アクセスは局部的なままである。アクセスした第１のスロットを読み出した場合には、次のＳスロットも小さなＳに対して読み出され、ディスク動作は、（例えば、１２バイトの代わりに１Ｋを読み出すように）余分な時間はかからないし、オーバーフロー・スロットも提供する。新しいエントリが追加されると、複数のスロットを１つのグループとしてディスクに書戻すことができる。衝突チェーンがＳ個のスロットを超えて跨ることが希になるように（およびそれにより追加のディスク・アクセスが必要になるように）（おそらく動的に）値Ｓが調整される。
６．１７ハッシュ・テーブル・バケット
インデックスがディスク上に格納されている場合には、インデックスへのランダム・アクセス読出しおよび書込みは時間がかかるものになる場合がある。それ故、あるスロットから他のスロットに溢れるチャンスがある場合には、２つ以上のスロットを一度に読出しおよび書込みするのは理にかなっている。そうするための１つの方法は、テーブルをバケット２４０に分割し（図２４）、エントリのかわりにバケットを読み出し、書き込む方法である。例えば、１０２４のスロットのテーブルを、それぞれが１６のスロットを含む６４のバケットのテーブルで置き換えることができる。エントリを探索するために、バケットを読み出して、バケット内で線形探索を行うことができ（またはバケット内のキーがソートされる場合、二分探索をおそらく行うことができる）。時々であるがバケットが満杯になっている場合がある。その場合には、オーバーフローは次のバケットに移動する。テーブルがあまり大きく成長できない限りは、オーバーフロー・チェーンはあまり長くすべきではない。
６．１８ハッシュ・テーブルの成長
ハッシュ・テーブルを使用した場合の１つの問題は、満杯になった場合、拡張するはっきりした方法がないことである。 The problem with this approach is that if the hash table is large and located on disk, a series of very time-consuming random access seeks must be performed on disk after the collision chain. It is not to be. This is defined by H (K, X) = H (K, X−1) +1, ie overflowing to the next adjacent slot 230 (see FIG. 23) (which surrounds the end of the table). Can be avoided. In the case of this technology, access remains local. When reading the accessed first slot, the next S slot is also read for the smaller S, and the disk operation takes no extra time (eg, reading 1K instead of 12 bytes). It also provides an overflow slot. When a new entry is added, multiple slots can be written back to the disk as a group. The value S is adjusted (possibly dynamically) so that the collision chain rarely crosses over S slots (and thus requires additional disk access).
6.17 Hash Table Bucket If the index is stored on disk, random access reads and writes to the index can be time consuming. Therefore, when there is a chance of overflowing from one slot to another, it makes sense to read and write more than one slot at a time. One way to do this is to divide the table into buckets 240 (FIG. 24) and read and write buckets instead of entries. For example, a table of 1024 slots can be replaced with a table of 64 buckets, each containing 16 slots. To search for an entry, the bucket can be read and a linear search can be performed in the bucket (or a binary search can probably be performed if the keys in the bucket are sorted). Sometimes the bucket is full. In that case, the overflow moves to the next bucket. Unless the table can grow very large, the overflow chain should not be too long.
6.18 Hash Table Growth One problem with using a hash table is that there is no clear way to extend it when it is full.

この問題に対する１つのアプローチは、テーブルがけっして満杯にならないようにすることである。このことは、最初に、特定の用途の場合にけっして満杯にならないほど大きなハッシュ・テーブルを生成することにより行うことができる。しかし、ある用途の場合には、予めハッシュ・テーブル上の負荷を予測することができない場合があり、そのため他の解決方法を発見しなければならない。 One approach to this problem is to keep the table from becoming full. This can be done by first generating a hash table that is never too full for a particular application. However, in some applications, it may not be possible to predict the load on the hash table in advance, so another solution must be found.

１つのアプローチは、新しいもっと大きなハッシュ・テーブルを生成し、旧テーブル内のすべてのエントリを新テーブルに転送することによりハッシュ・テーブルを廃棄する方法である。転送中に両方のテーブルを保持するための十分なメモリが存在する限り、このアプローチは完全に実行可能な方法である。 One approach is to create a new larger hash table and discard the hash table by transferring all entries in the old table to the new table. As long as there is enough memory to hold both tables during the transfer, this approach is a fully feasible method.

もう１つのアプローチは、満杯になったらいつでもハッシュ・テーブルのサイズを２倍にし、第１の（旧）２５０の半体内のエントリの（約）半体を、第２の（新）２５１の半体に転送する方法である。図２５は、その方法を示す。最初のハッシュ・テーブルが２^Ｋのエントリを有している場合には、全キーの下のＫビットを、テーブルを索引するために使用することができる。テーブルが満杯になったら２倍に増大することができる。この新テーブルは、全キー２５４のＫ＋１の最も低いビットをキーとして使用する。現在使用しているキーの余分なビット（ビットＫ）は、２倍にしたテーブルの旧テーブルおよび新テーブルの半体を区別する。全キーの左側の残りは未使用のままである。あとは、そのビットＫが１である２倍にしたテーブルの旧半体内のエントリを新半体内の対応する位置に移動するだけでよい。実際には、オーバーフローがあるので、これより少し複雑になる。最初に、オーバーフローは、エントリがテーブルの旧半体内の「自然の」位置に位置していなくて、それ故、すべてのエントリを単に移動すると、ビットＫセットがいくつかのエントリを正しくない位置に移動する。このことは、再ハッシュが必要なことを意味する。第二に、旧半体内のエントリを除去すると、いくつかのオーバーフロー・チェーンが切断する場合があり、いくつかのエントリにアクセスできなくなる恐れがある。それ故、エントリを移動した場合、そのエントリのオーバーフロー・チェーンをギャップを埋めるためにもとに戻してやらなければならない。
６．１９サブブロック・インデックス部分キーの格納
インデックスのサイズを小さくする１つの方法は、各インデックス・エントリ内にインデックスのキーのコピーを格納しない方法である。例えば、インデックス・キーが、（サブブロックの）１２８ビットのＭＤ５ハッシュである場合には、インデックスのサイズを小さくする１つの方法は、インデックスのエントリ内のキーの一部だけを記録する方法である。 Another approach is to double the size of the hash table whenever it is full, and (about) half of the entries in the first (old) 250 half to half the second (new) 251 half. It is a method of transferring to the body. FIG. 25 shows the method. If the first hash table has ^2K entries, the K bits under all keys can be used to index the table. When the table is full, it can be doubled. This new table uses the lowest bit of K + 1 of all keys 254 as a key. The extra bit (bit K) of the key currently in use distinguishes between the old and new table halves of the doubled table. The rest on the left side of all keys remains unused. All that remains is to move the entry in the old half of the doubled table whose bit K is 1 to the corresponding position in the new half. In fact, it is a bit more complicated because of the overflow. First, the overflow is that the entry is not in a “natural” position in the old half of the table, so if you simply move all the entries, the bit K set will put some entries in the wrong position. Moving. This means that rehashing is necessary. Second, removing entries in the old half may break some overflow chains and make some entries inaccessible. Therefore, when an entry is moved, the entry's overflow chain must be restored to fill the gap.
6.19 Storage of Subblock Index Partial Keys One way to reduce the size of the index is to not store a copy of the index key in each index entry. For example, if the index key is a 128-bit MD5 hash (of a sub-block), one way to reduce the size of the index is to record only a portion of the key in the index entry. .

例えば、インデックスがハッシュ・テーブル１２０として実施される場合には、各ハッシュ・テーブル・エントリ１２２は、通常、クラスタ番号１２４およびサブブロック・ハッシュ１２６のコピーを含む（図１２）。これにより、インデックスのハッシュ・テーブル内の同じ位置に２つのサブブロックがハッシュされた場合には、２つのエントリを区別することができる。しかし、ハッシュが１２８ビット幅を有していて、各ハッシュの６４ビットだけを格納する場合には、エントリは、依然として区別することができるが、スペースの半分を使用することになる。 For example, if the index is implemented as a hash table 120, each hash table entry 122 typically includes a copy of the cluster number 124 and the sub-block hash 126 (FIG. 12). Thus, if two sub-blocks are hashed at the same position in the index hash table, the two entries can be distinguished. However, if the hash is 128 bits wide and stores only 64 bits of each hash, the entries will still be distinguishable but will use half of the space.

極端な場合、ハッシュ・テーブルは、任意のキーの任意の部分を含んでいない。代わりに、各サブブロック・ハッシュは、ハッシュ・テーブル内のある位置にハッシュし、その位置で発見したすべてのクラスタを探索しなければならない。これは、依然として記憶装置内のすべてのクラスタの線形探索より遥かに優れている。 In the extreme case, the hash table does not contain any part of any key. Instead, each sub-block hash must hash to a location in the hash table and search all clusters found at that location. This is still much better than a linear search of all clusters in the storage device.

最善のアプローチは、ハッシュのある部分は格納するが、すべてのハッシュは格納しない方法である。このことは、希な場合ではあるが、ハッシュ・テーブル内に２つ以上の一致するエントリが存在する場合があり、一組の一致するエントリに参照したすべてのクラスタを探索しなければならないことを意味する。エントリ内のハッシュの一部だけを格納すれば、いくつかのクラスタをチェックしなくてもすみ、しかも依然として完全なハッシュよりかなり少ないスペースしか使用しない十分な違いを提供する。
６．２０ＢＬＯＢの削除
ある用途の場合には、ＢＬＯＢを削除し、またＢＬＯＢを格納しなければならない場合がある。ＢＬＯＢの削除を行わなければならない場合がある。何故なら、ＢＬＯＢのスパン内で参照したすべてのサブブロックを単に削除する（次に、ＢＬＯＢのスパンおよびＢＬＯＢレコードを削除する）明らかなアプローチは、このような行為は、他の（削除していない）ＢＬＯＢの一部でもあるサブブロックを削除する恐れがあるために失敗するからである。もっと高度なアプローチが望ましい。 The best approach is to store some part of the hash, but not all hashes. This is rare, but there may be more than one matching entry in the hash table, and all clusters referenced to a set of matching entries must be searched. means. Storing only a portion of the hashes in the entry eliminates the need to check several clusters and still provides a sufficient difference that uses much less space than the full hash.
6.20 Deleting a BLOB For some applications, it may be necessary to delete the BLOB and store the BLOB. It may be necessary to delete the BLOB. Because the obvious approach to simply delete all sub-blocks referenced within the BLOB span (and then delete the BLOB span and BLOB record) is that this action is the other (not deleted) This is because a failure occurs because there is a possibility of deleting a sub-block which is also a part of BLOB. A more advanced approach is desirable.

ＢＬＯＢを削除するためのあるアプローチは、記憶装置内の各サブブロックに余分なメタデータを追加する方法である。基準カウント。サブブロックの基準カウントは、サブブロックを含む（ＢＬＯＢ内の）スパンの数を格納する。基準カウント・アプローチの場合には、サブブロックを含む新しいスパンが生成されると（すなわち、ＢＬＯＢ格納中に）サブブロックの基準カウントが増大し、このようなスパンが削除されると（すなわち、ＢＬＯＢ削除中に）この基準カウントが低減する。その基準カウントがゼロになった場合には、サブブロックを削除することができる。 One approach for deleting a BLOB is to add extra metadata to each sub-block in the storage device. Reference count. The subblock reference count stores the number of spans (within the BLOB) that contain the subblock. In the case of the reference count approach, when a new span containing a subblock is created (ie during BLOB storage), the subblock's reference count increases and such a span is deleted (ie BLOB). This reference count is reduced (during deletion). When the reference count reaches zero, the sub-block can be deleted.

基準カウント・アプローチを使用すれば、記憶システムは、ＢＬＯＢを削除することができる。しかし、ユーザはこの機能を必要としない。基準カウントの他の方法は、満了システムである。このシステムの場合、各ＢＬＯＢおよび各サブブロックは満了日を有する。ＢＬＯＢを格納した場合、ユーザは満了日を提供し、ＢＬＯＢが追加され、スパンの新しいリストが生成される。追加プロセスの一部として、スパン・リストが参照したサブブロックは、その前の満了日の最大値に設定したその満了日を有し、それらを新しく参照しているＢＬＯＢの日付を有する。ＢＬＯＢおよびサブブロックに満了日を表示すると、背景プロセスは、満了したＢＬＯＢおよびサブブロックを自由に削除することができる。
６．２１既存のファイル・システムを使用する実施形態
本発明の実施形態は、既存のファイル・システムの頂部上で実施することができる。図３１は、その構成方法を示す。 Using the reference counting approach, the storage system can delete the BLOB. However, the user does not need this function. Another method of reference counting is an expiration system. For this system, each BLOB and each sub-block has an expiration date. If the BLOB is stored, the user provides an expiration date, the BLOB is added, and a new list of spans is generated. As part of the add process, the subblock referenced by the span list has its expiration date set to the maximum of its previous expiration date and the date of the BLOB that is newly referencing them. When the expiration date is displayed in the BLOB and sub-block, the background process is free to delete the expired BLOB and sub-block.
6.21 Embodiment Using Existing File System Embodiments of the present invention can be implemented on top of an existing file system. FIG. 31 shows the configuration method.

このような実施形態の場合、各クラスタは、１つのクラスタ・ファイル３４０内に格納することができる。クラスタに番号が付けられている場合には、各クラスタの名前は、クラスタ番号を含むことができる。クラスタ・ファイルは、１つのディレクトリ３４２またはディレクトリのツリー３４４内に格納することができる（図３４）。クラスタはそのファイル上でランダム・アクセス読出しおよび書込みを行うことにより直接修正することもできるし、またはクラスタ・ファイルをメモリ内の完全な読み出し、それを修正し、およびシーケンシャルなＩＯ動作を使用して、全ファイルをディスクに書き戻すことにより修正することができる。 For such an embodiment, each cluster can be stored in one cluster file 340. If the clusters are numbered, the name of each cluster can include the cluster number. Cluster files can be stored in one directory 342 or directory tree 344 (FIG. 34). The cluster can be modified directly by doing random access reads and writes on the file, or the cluster file can be read completely in memory, modified, and using sequential IO operations. It can be modified by writing all files back to disk.

もう１つの実施形態は、既存のファイル・システムを使用することができるが、１つのファイルしか使用しない。クラスタは、メモリ内に保持しているクラスタインデックス３３２を使用することにより、隣接して位置する１つのファイル３３０内に格納することができる（図３３）。 Another embodiment can use an existing file system, but uses only one file. A cluster can be stored in one adjacent file 330 by using a cluster index 332 held in memory (FIG. 33).

固定長クラスタ・ディレクトリを使用する場合には、クラスタ・ディレクトリの一組全体を、ディレクトリを格納している１つのファイル内にアレイとして格納することができ、ファイルにランダム・アクセスを行って特定のディレクトリにランダム・アクセスすることができるようにする。 When using a fixed-length cluster directory, the entire set of cluster directories can be stored as an array in one file containing the directory, and the file can be accessed randomly Allow random access to the directory.

各ＢＬＯＢは、その名前がＢＬＯＢのハッシュの名前であるファイル内に格納することができる。ＢＬＯＢファイルは、ＢＬＯＢディレクトリ内、またはディレクトリ（おそらくＢＬＯＢハッシュの連続しているバイトにより構成されているデジタル探索ツリー）内に格納することができる。各ＢＬＯＢファイルは、ＢＬＯＢを表すスパンのリストを含むことができる。ファイル・システムのファイル毎のスペース・オーバーヘッドを避けるために、複数のＢＬＯＢを１つの「ＢＬＯＢ」ファイル内に格納することができる。
６．２２仮想ブロック装置を使用する実施形態
本発明の実施形態は、既存のオペレーティング・システム３２２が提供する仮想ブロック装置を使用して実施することができる（図３２）。クラスタは、メモリ内に保持しているクラスタインデックスを使用することにより、隣接して位置する仮想ブロック装置内に格納することができる。
６．２３データを格納しない実施形態
すでに説明した実施形態のいずれかと同じではあるが、任意のＢＬＯＢデータを実際に格納しない実施形態を生成することができる（図３５）。このような実施形態の場合には、すべての記憶構造およびメタデータを構成することができるが、ＢＬＯＢ／サブブロック・コンテンツは格納されない。この実施形態のような実施形態は、前に遭遇したＢＬＯＢ１に関連してＢＬＯＢ２を分析しなければならない用途の際に役に立つが、その場合、ＢＬＯＢを実際には格納してはならない。 Each BLOB can be stored in a file whose name is the name of the hash of the BLOB. BLOB files can be stored in a BLOB directory or in a directory (possibly a digital search tree composed of consecutive bytes of a BLOB hash). Each BLOB file can include a list of spans that represent the BLOB. To avoid space overhead per file in the file system, multiple BLOBs can be stored in one “BLOB” file.
6.22 Embodiment Using Virtual Block Device Embodiments of the present invention can be implemented using a virtual block device provided by an existing operating system 322 (FIG. 32). Clusters can be stored in adjacent virtual block devices by using a cluster index held in memory.
6.23 Embodiment not storing data An embodiment can be generated that is the same as any of the previously described embodiments but does not actually store any BLOB data (FIG. 35). In such an embodiment, all storage structures and metadata can be configured, but no BLOB / sub-block content is stored. Embodiments such as this embodiment are useful in applications where BLOB2 must be analyzed in relation to BLOB1 previously encountered, in which case the BLOB must not actually be stored.

例えば、セキュリティ環境においては、ＢＬＯＢコンテンツ自身を格納しないで、前に遭遇したＢＬＯＢに関連してＢＬＯＢを分析するためにＢＬＯＢメタデータを使用する方が有利な場合がある。記憶構造および既存のＢＬＯＢを表すメタデータを使用することにより、記憶装置は、前に遭遇したＢＬＯＢにアクセスしなくても、前に遭遇したＢＬＯＢの本体に関連して文書を分析することができる。例えば、このことはセキュアなゲートウェイに適用することができる。
６．２４範囲に関する注
当業者であれば、本発明は、上記の特定の用途に限定されないことを理解することができるだろう。また、本発明は、本明細書に記載し図面に示した特定の要素および／または機能に関してその好ましい実施形態に限定されない。本発明の原理から逸脱することなしに、種々の修正を行うことができることを理解することができるだろう。それ故、本発明は、本発明の範囲内に入るすべてのこのような修正を含むものと解釈すべきである。 For example, in a security environment, it may be advantageous to use BLOB metadata to analyze a BLOB in relation to a previously encountered BLOB without storing the BLOB content itself. By using the storage structure and metadata representing an existing BLOB, the storage device can analyze the document relative to the body of the previously encountered BLOB without having to access the previously encountered BLOB. . For example, this can be applied to a secure gateway.
6.24 Range Note One skilled in the art will appreciate that the present invention is not limited to the specific applications described above. In addition, the present invention is not limited to its preferred embodiments with respect to the specific elements and / or functions described herein and illustrated in the drawings. It will be understood that various modifications can be made without departing from the principles of the invention. Accordingly, the present invention should be construed as including all such modifications that fall within the scope of the invention.

ＢＬＯＢのサブブロックへの分割である。BLOB is divided into sub-blocks. クラスタ内のＢＬＯＢのサブブロックの記憶装置である。This is a storage device for BLOB sub-blocks in a cluster. ＢＬＯＢを、クラスタ内のサブブロックの一続きの部分を識別するスパンの順序付きリストとして表す方法である。A method of representing a BLOB as an ordered list of spans that identify a succession of sub-blocks within a cluster. データの共通シーケンス（サブブロックＡ〜ＣおよびＧ〜Ｊ）を含む２つの異なるＢＬＯＢを、各反復サブブロックを２回以上格納しないですむ方法で表す方法である。It is a way to represent two different BLOBs that contain a common sequence of data (sub-blocks A to C and G to J) in such a way that each repeated sub-block need not be stored more than once. サブブロックを含むクラスタの数に各サブブロックのハッシュをマッピングするインデックスを示す。Indicates an index that maps the hash of each sub-block to the number of clusters containing the sub-block. ＢＬＯＢを固定長サブブロックに分割する分割方法である。This is a division method for dividing BLOB into fixed-length sub-blocks. クラスタの開始のところにサブブロック・ディレクトリを含むサブブロックのクラスタである。A cluster of sub-blocks containing a sub-block directory at the start of the cluster. クラスタのディレクトリをクラスタ自身とは別々に格納する方法である。This is a method of storing the cluster directory separately from the cluster itself. クラスタ・サブブロック・ディレクトリのエントリをクラスタ全体に分配する方法である。This is a method of distributing cluster sub-block directory entries to the entire cluster. （格納しているＢＬＯＢの）サブブロックＡがクラスタ＃１内にすでに存在することを発見した後で、ＢＬＯＢ内の以降のサブブロック（Ｂ、ＣおよびＤ）をそのクラスタ内でＡの後のサブブロック（この場合は、Ｂ、ＣおよびＤ）と比較することができ、それによりサブブロック・インデックス内のＢ、ＣおよびＤを参照しなくてもすむＢＬＯＢを格納する態様を示す。After discovering that subblock A (of the storing BLOB) already exists in cluster # 1, subsequent subblocks (B, C, and D) in BLOB are placed after A in that cluster. Fig. 4 illustrates how a BLOB is stored that can be compared with sub-blocks (in this case, B, C, and D), thereby avoiding reference to B, C, and D in the sub-block index. それぞれが、ＢＬＯＢ内のサブブロックを識別するスパンの順序付きリストを含む（または参照する）ＢＬＯＢレコードにＢＬＯＢハッシュをマッピングするＢＬＯＢテーブルである。Each is a BLOB table that maps a BLOB hash to a BLOB record that includes (or references) an ordered list of spans that identify sub-blocks within the BLOB. サブブロック・インデックス・ハッシュ・テーブルであり、テーブルのエントリである。It is a sub-block index hash table and is an entry of the table. （従来技術）データの同じサブ・シーケンスの２つの例を含む２つのファイルである。さらに、ファイルＡは、それ自身の中に同一のファイルを有する。(Prior Art) Two files containing two examples of the same sub-sequence of data. Furthermore, file A has the same file in itself. （従来技術）従来の記憶システムのその共通データを識別しようとしないファイルの格納方法である。(Prior Art) A file storage method that does not attempt to identify the common data of a conventional storage system. （従来技術）従来のデータ圧縮が各ＢＬＯＢのサイズを小さくするが、ＢＬＯＢ間のデータの共通シーケンスを識別しないことを示す。(Prior Art) Shows that conventional data compression reduces the size of each BLOB, but does not identify a common sequence of data between BLOBs. データの同じシーケンスを含む２つのＢＬＯＢの表示が、データのこれらのシーケンスを参照し、そのためシーケンスを１回格納するだけですむ方法である。Displaying two BLOBs that contain the same sequence of data is a way to reference these sequences of data and thus store the sequence only once. 任意の部分一致があるか否かをチェックするために、一致する一続きの部分の各端部のところのサブブロックを直接比較する方法である。In order to check whether there is any partial match, it is a method of directly comparing the sub-blocks at each end of a series of matching parts. 一続きの部分の両端のところに部分サブブロックを含むサブブロックの一続きの部分を表すために（それぞれがバイト・カウントを保持する）２つの追加フィールド「開始スキップ」および「終了スキップ」で、スパン・レコードを増大する方法である。In two additional fields "start skip" and "end skip" (each holding a byte count) to represent a series of sub-blocks containing partial sub-blocks at both ends of the series of parts, A way to increase spanned records. ＢＬＯＢを格納した場合に、孤立している一致サブブロック（Ｃ）がＢＬＯＢの表示で分割を行う方法である。In this method, when a BLOB is stored, an isolated matching sub-block (C) is divided by displaying the BLOB. 記憶装置で孤立サブブロック（Ｃ）を２回格納することを選択することにより分割を避ける方法である。This is a method of avoiding division by selecting to store the isolated sub-block (C) twice in the storage device. ２つのキーが、テーブル内の同じ位置にハッシュするハッシュ・テーブル衝突を示す。Two keys indicate a hash table collision that hashes to the same location in the table. 外部オーバーフロー・リストを含むハッシュ・テーブルである。A hash table that contains an external overflow list. オーバーフロー・エントリが次の空のスロットに格納されるテーブル内オーバーフローである。Overflow in table where overflow entry is stored in next empty slot. それぞれが一定数のエントリ・スロットを含むバケットのアレイとして構成されたハッシュ・テーブルである。A hash table configured as an array of buckets each containing a fixed number of entry slots. 全キーの余分なビットを使用してハッシュ・テーブルのサイズを２倍にする方法である。This is a method of doubling the size of the hash table using extra bits of all keys. ３つの分岐を含むスパンのツリーである。スパンをツリーに編成することにより、ＢＬＯＢ内のランダム・アクセスが高速になる。図面の番号は、各子ノードが表すブロックの長さである。A tree of spans containing three branches. By organizing spans into trees, random access within a BLOB is faster. The number in the drawing is the length of the block represented by each child node. 元のＢＬＯＢ内で隣接しているサブブロックの一続きの部分を識別するためのクラスタ内のサブブロックの一連番号の意図的なスキップである。Intentional skip of the sequence number of the sub-blocks in the cluster to identify a succession of adjacent sub-blocks in the original BLOB. ２つのサブブロックＡおよびＢを直接比較しないで、これらのサブブロックＡおよびＢを比較する暗号ハッシュ関数Ｈの使用方法である。代わりに、そのハッシュＨ（Ａ）およびＨ（Ｂ）が比較される。This is a method of using a cryptographic hash function H that compares two sub-blocks A and B without comparing them directly. Instead, its hashes H (A) and H (B) are compared. サブブロックＡ、Ｂ、ＣおよびＤを索引し、そのキーが、サブブロック自身ではなく、（ハッシュ関数Ｈを使用する）サブブロックのハッシュであるサブブロック・インデックスである。Index the sub-blocks A, B, C and D, and the sub-block index whose key is the hash of the sub-block (using the hash function H), not the sub-block itself. サブブロックに分割され、低冗長記憶装置に格納されたにも関わらず、ＢＬＯＢがその統合性を保持していることをチェックするための暗号ハッシュ関数Ｈの使用方法である。元のＢＬＯＢのハッシュは、格納しているＢＬＯＢと一緒に格納され、検索したＢＬＯＢのハッシュと比較される。This is a method of using a cryptographic hash function H for checking that a BLOB retains its integrity even though it is divided into sub-blocks and stored in a low redundancy storage device. The original BLOB hash is stored along with the stored BLOB and compared to the retrieved BLOB hash. 既存のファイル・システム（の頂部上）を使用して低冗長記憶システムが実施される実施形態である。An embodiment in which a low redundancy storage system is implemented using an existing file system (on top). 既存のオペレーティング・システムが提供する仮想ブロック装置（の頂部上）を使用して低冗長記憶システムを実施する実施形態である。FIG. 2 is an embodiment implementing a low redundancy storage system using (on top of) a virtual block device provided by an existing operating system. １つのブロック装置またはファイル・システム内の１つのファイル内に、長さが変化するクラスタを格納する方法である。クラスタ・インデックスは、その番号によりクラスタを迅速に発見するために使用することができる。A method of storing clusters of varying lengths in one block device or one file in a file system. The cluster index can be used to quickly find a cluster by its number. 既存のファイル・システム内のファイルの対応する集合体内へのクラスタの集合体の格納方法である。この例の場合には、ディレクトリ・ツリーは、クラスタ番号上の小数デジタル探索ツリーを形成する。A method for storing a collection of clusters in a corresponding collection of files in an existing file system. In this example, the directory tree forms a decimal digital search tree on the cluster number. ＢＬＯＢを格納するために必要な構造およびメタデータを生成したが、データ自身を格納していない実施形態である。In this embodiment, the structure and metadata necessary for storing the BLOB are generated, but the data itself is not stored. 元のスパン（サブブロックＦＧＨ）と同じデータを指しているが、記憶装置の異なる部分（この場合は、異なるクラスタ）内に位置する別のスパンにより増大したスパン（スパンのリスト内の２番目）である。A span (second in the list of spans) that points to the same data as the original span (sub-block FGH) but is augmented by another span located in a different part of the storage device (in this case, a different cluster) It is. 制約Ｆを使用するサブブロックへのブロックｂの分割、およびハッシュ関数Ｈを使用するサブブロックのハッシュの計算を示す。Fig. 4 shows the partitioning of block b into sub-blocks using constraint F and the computation of the sub-block hash using hash function H. 典型的なコンピュータ・ハードウェア上での低冗長記憶システムの配置方法である。すべてのデータ構造は、ディスク上に常駐している。また、インデックスも、いくつかのＢＬＯＢレコードおよびクラスタの作業コピーを格納しているいくつかのキャッシュと一緒にメモリ内に保持される。This is a method of placing a low redundancy storage system on typical computer hardware. All data structures reside on disk. The index is also maintained in memory along with several caches storing several BLOB records and a working copy of the cluster.

Claims

ＢＬＯＢ（バイナリー・ラージ・オブジェクト）を複数のサブブロックに分割するステップと、
前記サブブロックを複数のクラスタ内に格納するステップと、
前記ＢＬＯＢに基づいて複数のスパンを生成するステップと、からなり、
前記複数のスパンは、前記ＢＬＯＢを表示し、
各スパンは前記クラスタ内のサブブロックのシーケンスを特定し、少なくとも１つのサブブロックが１つの以上のスパンにより参照される、
ＢＬＯＢを格納する方法。Dividing a BLOB (binary large object) into a plurality of sub-blocks;
Storing the sub-block in a plurality of clusters;
Generating a plurality of spans based on the BLOB; and
The plurality of spans display the BLOB,
Each span identifies a sequence of sub-blocks in the cluster, wherein at least one sub-block is referenced by one or more spans;
A method of storing a BLOB.

各スパンが、クラスタ内の１つまたは複数の隣接サブブロックのシーケンスを識別する、請求項１に記載の方法。 The method of claim 1, wherein each span identifies a sequence of one or more adjacent sub-blocks in the cluster.

前記複数のスパンが順序付きリストである、請求項１に記載の方法。 The method of claim 1, wherein the plurality of spans is an ordered list.

前記複数のスパンがスパンのツリーである、請求項１に記載の方法。 The method of claim 1, wherein the plurality of spans is a tree of spans.

２つ以上のサブブロックが、介入メタデータを使用しないでクラスタ内にバイトの隣接シーケンスとして格納される、請求項１に記載の方法。 The method of claim 1, wherein two or more sub-blocks are stored as contiguous sequences of bytes in a cluster without using interventional metadata.

前記サブブロックが、いくつかのサブブロック・メタデータとインタリーブしている、請求項１に記載の方法。 The method of claim 1, wherein the sub-block is interleaved with some sub-block metadata.

各スパンが、クラスタ識別子、クラスタ・アドレス、サブブロック識別子、クラスタ内のサブブロック位置、長さのうちの少なくとも１つを使用して、クラスタ内の隣接サブブロックのシーケンスを特定する、請求項１に記載の方法。Each span is, cluster identifier, cluster address, sub-block identifier, the sub-block positions in the cluster, using at least one of the length and specific sequence of adjacent sub blocks in the cluster, according to claim 1 The method described in 1.

前記長さがサブブロック数である、請求項７に記載の方法。 The method of claim 7, wherein the length is the number of subblocks.

前記長さがバイト数である、請求項７に記載の方法。 The method of claim 7, wherein the length is a number of bytes.

上部境界が、各クラスタ内のサブブロック数上に置かれる、請求項１に記載の方法。 The method of claim 1, wherein the upper boundary is placed on the number of subblocks in each cluster.

上部境界が、各クラスタ内のバイト数上に置かれる、請求項１に記載の方法。 The method of claim 1, wherein the upper boundary is placed on the number of bytes in each cluster.

前記ＢＬＯＢを分割するステップが、前記一組のＢＬＯＢをＢＬＯＢ内の少なくとも１つの位置ｋ｜ｋ＋１のところで複数のサブブロックに分割することにより分割されることを含み、分割位置［ｋ−Ａ＋１．．ｋ＋Ｂ］（ＡおよびＢが自然数である）、が所定の制約を満たす、請求項１に記載の方法。 Dividing the BLOB is the set of BLOB least one position k in the BLOB | and a this divided by dividing the k + plurality of sub-blocks at the 1, division position [k-A + 1. . The method of claim 1, wherein k + B] (where A and B are natural numbers) satisfies a predetermined constraint .

前記データを格納する前記データ構造が生成されるが、前記データ自身は格納されない、請求項１に記載の方法。 The method of claim 1, wherein the data structure for storing the data is generated, but the data itself is not stored.

各クラスタが、サブブロックのディレクトリを有し、前記ディレクトリが、各サブブロックの長さ、各サブブロックのハッシュ、前記クラスタ内の各サブブロックの位置、各サブブロックに対する識別子のうちの少なくとも１つを含む、請求項１に記載の方法。 Each cluster has a directory of subblocks, and the directory is at least one of the length of each subblock, the hash of each subblock, the location of each subblock in the cluster, and the identifier for each subblock. The method of claim 1 comprising:

前記クラスタ・ディレクトリが、前記クラスタ内に格納される、請求項１４に記載の方法。The method of claim 14 , wherein the cluster directory is stored in the cluster.

前記クラスタ・ディレクトリが、前記クラスタとは別々に格納される、請求項１４に記載の方法。The method of claim 14 , wherein the cluster directory is stored separately from the cluster.

前記クラスタ・ディレクトリが、前記クラスタが含むサブブロック数が何であれ固定長である、請求項１４に記載の方法。The method of claim 14 , wherein the cluster directory is a fixed length whatever the number of subblocks the cluster contains.

前記クラスタ・ディレクトリが固定長であり、クラスタ・ディレクトリの固定長アレイ内に前記クラスタとは別々に格納される、請求項１４に記載の方法。The method of claim 14 , wherein the cluster directory is fixed length and is stored separately from the cluster in a fixed length array of cluster directories.

前記クラスタが、前記クラスタ内のサブブロックの隣接する一続きの部分間の境界を記録する、請求項１４に記載の方法。The method of claim 14 , wherein the cluster records a boundary between adjacent runs of subblocks in the cluster.

クラスタ内のサブブロック間の境界が、順序付き識別子を使用することにより、および境界のところでサブブロックに隣接していない識別子を割り当てることにより特定される、請求項１４に記載の方法。Boundary between the sub-blocks in the cluster, by using the ordered identifier and is identified by assigning an identifier that is not adjacent to the sub-block at the boundary The method of claim 14.

圧縮アルゴリズムを使用して少なくとも１つのクラスタを圧縮するステップをさらに含む、請求項１に記載の方法。 The method of claim 1, further comprising compressing at least one cluster using a compression algorithm.

圧縮アルゴリズムを使用して少なくとも１つのサブブロックを圧縮するステップをさらに含む、請求項１に記載の方法。 The method of claim 1, further comprising compressing at least one sub-block using a compression algorithm.

少なくとも２つの隣接サブブロックが、圧縮アルゴリズムを使用することにより圧縮される、請求項１に記載の方法。 The method of claim 1, wherein at least two adjacent sub-blocks are compressed using a compression algorithm.

少なくとも１つのサブブロックを前記サブブロックを含む前記クラスタにマッピングするインデックスを維持するステップをさらに含む、請求項１に記載の方法。 The method of claim 1, further comprising maintaining an index that maps at least one sub-block to the cluster that includes the sub-block.

少なくとも１つのサブブロックのハッシュを、前記サブブロックを含む前記クラスタにマッピングするインデックスを維持するステップをさらに含む、請求項１に記載の方法。 The method of claim 1, further comprising maintaining an index that maps a hash of at least one sub-block to the cluster that includes the sub-block.

前記インデックスが、前記サブブロックを含む前記クラスタ内の各サブブロックの位置を含む、請求項２４または２５に記載の方法。 26. A method according to claim 24 or 25 , wherein the index comprises the position of each sub-block in the cluster containing the sub-block.

前記インデックスが、そのキーがサブブロック・ハッシュであるデジタル探索ツリーとして実施される、請求項２４または２５に記載の方法。 26. A method according to claim 24 or 25 , wherein the index is implemented as a digital search tree whose key is a sub-block hash.

前記インデックスが、Ｂツリーとして実施される、請求項２４に記載の方法。The method of claim 24 , wherein the index is implemented as a B-tree.

各ＢＬＯＢ内の各Ｔ番目のサブブロックだけが索引され、Ｔが所定の正の整数である、請求項２４に記載の方法。25. The method of claim 24 , wherein only each Tth sub-block in each BLOB is indexed and T is a predetermined positive integer.

各ＢＬＯＢ内の各Ｔ番目のサブブロックだけが索引され、Ｔが所定の正の整数である、請求項２５に記載の方法。 26. The method of claim 25 , wherein only each Tth sub-block in each BLOB is indexed and T is a predetermined positive integer.

前記インデックスが、１つまたは複数のハッシュ・テーブルとして実施される、請求項２４に記載の方法。The method of claim 24 , wherein the index is implemented as one or more hash tables.

サブブロックに対するハッシュ・テーブル・エントリが、前記サブブロックの前記ハッシュの全部または一部を含む、請求項３１に記載の方法。32. The method of claim 31 , wherein a hash table entry for a subblock includes all or part of the hash of the subblock.

前記ハッシュ・テーブルがバケットを含む、請求項３１に記載の方法。32. The method of claim 31 , wherein the hash table includes buckets.

各スパンが、前記クラスタ内の１つまたは複数のバイトの有限シーケンスを参照する、請求項１に記載の方法。 The method of claim 1, wherein each span references a finite sequence of one or more bytes in the cluster.

各スパンが、Ｘバイトだけ低減する前記スパンの範囲を示す少なくとも１つのスキップ値Ｘを含む、請求項１に記載の方法。 The method of claim 1, wherein each span includes at least one skip value X indicating a range of the span that is reduced by X bytes.

各スパンが、Ｘバイトだけ増大する前記スパンの範囲を示す少なくとも１つの拡張値Ｘを含む、請求項１に記載の方法。 The method of claim 1, wherein each span includes at least one extension value X indicating a range of the span that increases by X bytes.

クラスタにサブブロックを追加する前に、前記インデックスをチェックすることによりサブブロックの複製をチェックするステップを含む、請求項２４に記載の方法。25. The method of claim 24 , comprising checking subblock replication by checking the index prior to adding a subblock to a cluster.

格納するサブブロックのハッシュを、クラスタ内の前記サブブロックのうちの少なくとも１つの前記ハッシュと比較することにより、サブブロックの複製をチェックするステップであって、インデックスが格納するサブブロックを示すステップを含む、請求項２５に記載の方法。Checking a replica of the subblock by comparing a hash of the subblock to be stored with the hash of at least one of the subblocks in the cluster, the step indicating the subblock that the index stores 26. The method of claim 25 , comprising.

スパンが、前記サブブロックの前記ハッシュの一部または全部を使用してサブブロックを特定する、請求項１に記載の方法。The method of claim 1, wherein a span identifies a sub-block using part or all of the hash of the sub-block.

Ｔの現在のサブブロック以下の少なくとも１つの隣接する一続きの部分が、サブブロックの記憶装置内で複製され、Ｔがサブブロックの所定のしきい値である、請求項１に記載の方法。 2. The method of claim 1, wherein at least one contiguous stretch of T or less of the current sub-block is replicated in the sub-block storage, and T is a predetermined threshold of the sub-block.

Ｔが２である、請求項４０に記載の方法。41. The method of claim 40 , wherein T is 2.

１つまたは複数のサブブロックの少なくとも１つの隣接する一続きの部分が、サブブロックの前記記憶装置内で複製される、請求項１に記載の方法。 The method of claim 1, wherein at least one adjacent stretch of one or more sub-blocks is replicated in the storage device of a sub-block.

少なくとも１つのスパンＸが、スパンＸにより参照されたデータのコピーを参照する別のスパンにより増大する、請求項１に記載の方法。 The method of claim 1, wherein at least one span X is augmented by another span that references a copy of the data referenced by span X.

前記インデックスをクラスタ内のサブブロックＸの位置の発見に使用した場合に、格納中の前記サブブロックによりサブブロックの最も長い一致する一続きの部分を発見するために、前記クラスタがサブブロックＸから順方向に探索される、請求項２４に記載の方法。When the index is used to find the location of sub-block X in the cluster, the cluster is identified from sub-block X to find the longest matching sequence of sub-blocks by the sub-block being stored. 25. The method of claim 24 , searched in the forward direction.

前記インデックスをクラスタ内のサブブロックＸの位置の発見に使用した場合に、格納中の前記サブブロックによりサブブロックの最も長い一致する一続きの部分を発見するために、前記クラスタがサブブロックＸから順方向に探索される、請求項２５に記載の方法。When the index is used to find the location of sub-block X in the cluster, the cluster is identified from sub-block X to find the longest matching sequence of sub-blocks by the sub-block being stored. 26. The method of claim 25 , searched in the forward direction.

ＢＬＯＢを２つ以上のサブブロックに分割するためのデータ処理手段と、
１つまたは複数のクラスタ内に前記サブブロックを格納し、そして前記ＢＬＯＢに基づきＢＬＯＢを表示する、複数のスパンを生成し、該スパンの順序付きリストまたは、該スパンのツリーを格納するためのデータ記憶手段と、を備え、
前記各スパンがクラスタ内の１つまたは複数の隣接サブブロックのシーケンスを特定し、少なくとも１つのサブブロックが、１つ以上のスパンにより参照される、
ＢＬＯＢを格納するためのデータ処理装置。Data processing means for dividing the BLOB into two or more sub-blocks;
Data for generating a plurality of spans storing the sub-blocks in one or more clusters and displaying a BLOB based on the BLOB , and storing an ordered list of the spans or a tree of the spans Storage means,
Each span identifies a sequence of one or more adjacent sub-blocks in the cluster, wherein at least one sub-block is referenced by one or more spans;
Data processing device for storing BLOB.

前記処理手段が、各サブブロックを、前記サブブロックを含む前記クラスタにマッピングするインデックスを維持する、請求項４６に記載のデータ処理装置。The data processing apparatus according to claim 46, wherein the processing means maintains an index that maps each sub-block to the cluster including the sub-block.

前記処理手段が、クラスタにサブブロックを追加する前に、前記インデックスをチェックすることによりサブブロックの複製をチェックする、請求項４６に記載のデータ処理装置。 47. The data processing apparatus according to claim 46, wherein the processing means checks the duplication of the subblock by checking the index before adding the subblock to the cluster.

データのＢＬＯＢを格納するためのプログラマブル・デバイスを指示するために使用することができる、コンピュータ・プログラムを表すデータで符号化したコンピュータ可読メモリであって、
前記ＢＬＯＢを２つ以上のサブブロックに分割するための、前記コンピュータ可読メモリを動作するための処理手段と、
１つまたは複数のクラスタ内に前記サブブロックを格納し、前記ＢＬＯＢに基づいてＢＬＯＢを表示する複数のスパンを生成し、該スパンの順序付きリストまたは、該スパンのツリーを記憶するための、前記コンピュータ可読メモリにより使用することができるデータ記憶手段と、を備え、
各スパンが、クラスタ内の１つまたは複数の隣接サブブロックのシーケンスを特定し、少なくとも１つのサブブロックが、１つ以上のスパンにより参照される、
コンピュータ可読メモリ。A computer readable memory encoded with data representing a computer program that can be used to direct a programmable device for storing a BLOB of data,
Processing means for operating the computer readable memory to divide the BLOB into two or more sub-blocks;
Storing the sub-blocks in one or more clusters, generating a plurality of spans displaying a BLOB based on the BLOB, and storing an ordered list of the spans or a tree of the spans ; Data storage means that can be used by a computer readable memory,
Each span identifies a sequence of one or more adjacent sub-blocks in the cluster, and at least one sub-block is referenced by one or more spans;
Computer readable memory.

前記処理手段が、各サブブロックを前記サブブロックを含む前記クラスタにマッピングするインデックスを維持する、請求項４９に記載のコンピュータ可読メモリ。50. The computer readable memory of claim 49 , wherein the processing means maintains an index that maps each sub-block to the cluster containing the sub-block.

前記処理手段が、クラスタにサブブロックを追加する前に、前記インデックスをチェックすることによりサブブロックの複製をチェックする、請求項５０に記載のコンピュータ可読メモリ。51. The computer readable memory of claim 50 , wherein the processing means checks for subblock replication by checking the index before adding a subblock to a cluster.

プログラマブル・デバイスに、
ＢＬＯＢを複数のサブブロックに分割する第１の機能と、
前記サブブロックを複数のクラスタに格納する第２の機能と、
前記ＢＬＯＢに基づいて、ＢＬＯＢを表示する、関連する一群のスパンを生成する第３の機能と、
を実行させるために、データとしてのＢＬＯＢを格納するためのコンプータ・プログラムコード手段を備えるコンピュータ・プログラム要素であって、
前記各スパンが、クラスタ内の１つまたは複数の隣接サブブロックのシーケンスを識別し、少なくとも１つのサブブロックが、１つ以上のスパンにより参照される
コンピュータ・プログラム要素。To programmable devices,
A first function for dividing the BLOB into a plurality of sub-blocks;
A second function of storing the sub-block in a plurality of clusters;
A third function for generating a related group of spans based on the BLOB and displaying the BLOB;
A computer program element comprising computer program code means for storing a BLOB as data in order to execute
Wherein each span, one or more identifying sequences of adjacent sub blocks, at least one sub-block, the computer program element referenced by one or more spans in the cluster.

第４の機能が、各サブブロックを、前記サブブロックを含む前記クラスタにマッピングするインデックスを維持する、請求項５２に記載のコンピュータ・プログラム要素。 53. The computer program element of claim 52 , wherein a fourth function maintains an index that maps each subblock to the cluster that includes the subblock.

第５の機能が、クラスタにサブブロックを追加する前に、前記インデックスをチェックすることによりサブブロックの複製をチェックする、請求項５３に記載のコンピュータ・
プログラム要素。54. The computer of claim 53 , wherein a fifth function checks for duplication of subblocks by checking the index before adding subblocks to a cluster.
Program element.