1

低速の転送メディアを介して「大きな」データセットの整合性を部分的にチェックする効率的な手段を探しています。ファイルサイズが転送速度に比例して大きくなるため、これはよくある問題のようです。

たとえば、具体的な数値の場合、USB2 を介したテラバイトのデータです。すべてのバイトをハッシュまたはチェックサムに読み取ってこのデータがまだ有効であることを確認するには、1 日を要し、ドライブ障害のリスクが高まります。

代わりに、このコードはデータのランダムな部分を検証し、利用可能な時間に基づいて有効性の確率を提供する必要があります。十分に長く実行できる場合、すべてのブロックが検証されます (データセット全体を読み取る基本ケース)。

使用法「ストーリー」:
-- 暗号化された大きなコンテナ (サイズ 1TB .. 1GB) に格納されたデータ。
-- 各コンテナは、異なる場所にある複数のドライブ セットに冗長的にバックアップされました。
-- 検証チェックは、基礎となるデータまたはキーを知らなくても実行する必要があります。

アプローチが検出するために必要な障害モード:
- ストレージ トランスポート障害 (コントローラーが物理アドレスの一部を削除するなど) - セクター エラー (特定のブロックに対してデータが返されない)
- シングル ビット エラー (非 ECC メモリまたはキャッシュ)

エラーが検出されると、データは冗長ストレージから回復されます。検証データは、おそらく別個に保管する必要があります。

目標はデータの整合性であるため、ファイル共有ネットワークの手法は適用できないようです。「ハッシュ ツリー」では、各ノードでハッシュの完全なストレージが必要になります。攻撃者。

  • ストレージ容量とファイルの関連ブロックを読み取る時間とのトレードオフをどのように判断できますか?
  • ハッシュツリー/ハッシュリストが最善の方法である場合、ハッシュの部分的な値を保存するのはどのくらい安全ですか?
  • チェックサムまたはエラー修正コードは、同等の保護のためにハッシュよりも優れた選択肢でしょうか?
4

3 に答える 3

2

転送は USB2 で行われますよね？したがって、次のことを知っておく必要があります。

  • USB 通信はパケット形式で、高速転送用の最大 1024 バイトのペイロードと 16 ビットの CRC を備えています。
  • 各パケットは確認応答され、場合によっては再送信されます。

これらの情報を考慮して、CRC によって提供されるものにいくつかの保証を追加するアルゴリズムを展開する必要があります。そうしないと、無駄になります。私がよく覚えていれば、16 ビット CRC は 16 ビットより長くない単一のエラー バーストと、それより長いものの一部を検出できます。

ウィキペディアから開始できます: http://en.wikipedia.org/wiki/USB2およびhttp://en.wikipedia.org/wiki/Cyclic_redundancy_check。

于 2008-11-23T10:25:19.230 に答える
1

You might want to try using something like PAR2 to create redundancy data. this will allow you to both check and correct data, and would probably be convertible to use random access.

于 2008-11-24T08:45:20.603 に答える
0

ファイル内の一連のデータのハッシュ値またはチェックサム値を保存するのはどうですか? ファイル コンテンツの限定的な検証のために、データの制限された部分を読み込むだけで済みます。

于 2008-11-23T05:55:39.680 に答える