上記のようにウィキペディアそしてArch Linux Wiki「Parchive」は追加データを生成するために使用できfile、確認に使用でき、ファイルが部分的に破損した場合（例えばHDDの4Kブロックを読み取れない場合）、そのファイルをある程度回復/復元するのにも使用できます。
ワークロード（追加の冗長回復データを格納するためのCPUとメモリ）を考慮すると、ブロックデバイスでパーカイブの概念を使用する方法はありますか？私は想像します
/dev/sdX/dev/sdX1ストレージの90％/dev/sdX2を占めるpar2。/dev/sdX1
改善されたデータの整合性のために、いくつかのCPUとストレージを犠牲にする価値を考慮すると、これらの機能を提供できるLinuxカーネルモジュール（機能関連）もあると想像しています（多分機能の一部device mapperですか？）。software raid
最後に、問題に関連する側面があります。データの損失を防ぐためにこのアーカイブメカニズムを使用する一般的なファイルシステムはありますか？ （zfsある種の保護機能があり、ext4重要なコンテンツの複数のコピーを保存することが知られているので、同様の機能も持つことができるsuperblockことを知っていますparchive。）
答え1
Parchive/par2が使用される長いパリティデータを計算する時間です。たとえば、私はpar2を使ってファイルをBlu-rayで焼きましたが、最新のシステムでは約10％のパリティデータで約1時間かかりました。これはデータ量とパリティに応じて拡張されるため（線形か悪いかはわかりません）、合理的なサイズのブロックデバイスでは数日かかります。数学的に言えば、ファイルの変更を最適化する方法があるかどうかはわかりません。それ以外の場合は、すべての書き込みに完全パリティ再計算が必要です。
他のパリティ方式は、ブロックデバイスで一般的に使用されます。 RAID5とRAID6はどちらもパリティ方式です。ほとんどのRAIDシステム（ソフトウェアとハードウェア）はこれをサポートしています。