ZFSとBtrfsはチェックサムを使用して、データ劣化また、Git はコミットごとに基本的にすべてをハッシュすることで整合性を保つと読みました。
私はストレージに Btrfs RAID 1 を搭載した Linux NAS 上の Git サーバーを使用するつもりでしたが、Git に整合性があれば、これは必要ないと思います (少なくとも、データ劣化を防ぐことだけが目的であれば)。
質問： では、コミットごとに基本的にすべてをハッシュする Git の整合性は、ビット腐食を防止したり、ビット腐食を軽減したりするのでしょうか?
答え1
Git のハッシュ化はコミットが作成された時点でのみ行われ、それ以降はハッシュがコミットを識別するために使用されます。これはファイルの整合性を保証するものではありません。Git リポジトリは破損してデータが失われることがあります。実際、Git にはこのような損失を検出するための組み込みコマンドがあります。git の fsckただし、ドキュメントに記載されているように、バックアップから破損したデータを復元する責任はユーザーにあります。
答え2
「防止する」の意味によって異なります。
（まず、ビット腐敗は複数の定義を持つ用語です。この質問はないについてメンテナンス不足によりコードが実行不能になる。
「防止」とは、ビットの劣化による破損を検出することを意味するのであれば、はい、それは機能します。ただし、ないその破損を修正するのに役立ちます：ハッシュはエラーのみを提供します修正ではなく検出。
これが一般的に「完全性」が意味するものです。検出するデータの不正な/意図しない操作は防止または修正できない可能性があります。
一般的には、RAID1 とバックアップ (ZFS スナップショットなどで実装される可能性がありますが、RAID1 + スナップショットの ZFS セマンティクスについてはよく知りません) を組み合わせることをお勧めしますが、それにはいくつかの理由があります。
ディスクに致命的な障害が発生した場合、データを復元するには RAID1 (または最新のバックアップ) が必要です。ディスクにデータの完全なコピー (RAID1) がない限り、エラー修正ではディスク全体の障害を修復できません。ダウンタイムが短い場合は、基本的に RAID1 が必要です。
リポジトリの一部または全体を誤って削除した場合は、バックアップが必要です (RAID1 では変更がすべてのデバイスに即座に反映されるため、保護されません)
ブロックレベルのRAID1（LVMなど）は、2つのディスクのみで構成され、ないしかし、データのサイレントデクリエーションからあなたを守ることはできません。RAIDコントローラは、2つのディスクのどちらが正しいデータを保持しているかを知ることができません。そのためには、ファイルのチェックサムなどの追加情報が必要です。ここで、ZSFとbtrfsのチェックサムが役立ちます。これらは使用できます（ただし、はこのような場合に使用されるディスク (ZFS または btrfs がそこでどのように処理するかはわかりません) は、2 つのディスクのどちらに正しいデータが格納されているかを区別します。
答え3
ビットの腐敗を防ぐ
いいえ、まったくそうではありません。git によって RAID のような冗長性は導入されません。ディレクトリ内のファイルが.gitビット劣化を起こした場合、通常どおりデータが失われます。
ビット腐食対策にいかがでしょうか?
うーん...いいえ。ビット腐敗の発生を防ぐことはできませんが、ビット腐敗の検出には役立ちます。ただし、通常の使用中に、独自のアカウントでこれを行うことはありません (一部のオブジェクトをチェックアウトするときなどは当然行われますが、履歴に対しては行われません)。コンテンツからハッシュを再計算し、実際のハッシュと比較するための cron ジョブを作成する必要があります。ハッシュはgit文字通りコンテンツのハッシュであるため、これを行うのは非常に簡単です。ハッシュを再計算するのは簡単で、git fsck自動的に実行されます。ただし、ビット腐敗が検出された場合、特にそれに対してできることは何もありません。具体的には、大きなチャンクは自動的に圧縮されるため、大きなオブジェクトのビットが反転すると、チャンク全体が失われる可能性があります。