Gitはデータの劣化を防ぎますか
私は、ZFSとBtrfsが データの劣化 を防ぐためにチェックサムを使用していることを読み、Gitはコミットごとに基本的にすべてをハッシュすることによって整合性を保ちます。
私はストレージ用にBtrfs RAID 1を備えたLinux NAS上のGitサーバーを使うつもりでしたが、もしGitが完全性を持っていればこれは必要ないと思います）.
質問：それでは、コミットごとに基本的にすべてをハッシュすることによるGitの整合性は、ビットの腐敗を防ぎますか、それとも助けになりますか？
Gitのハッシュはコミットが作成されたときにのみ行われ、そこからハッシュがコミットを識別するために使用されます。これは決してファイルの整合性を保証するものではありません。 Gitリポジトリは破損してデータを失う可能性があります。実際、gitにはこの種の損失を検出するための組み込みコマンドがあります git fsck 。バックアップからの破損したデータ。
「予防」の意味に依存します。
（まず、ビットロートは複数の定義を含む用語です。この質問は not について コードがメンテナンス不足のため実行不能になる です。）
ビットの減衰による破損を検出する可能性が高いことを「防止」するという意味であれば、はい、機能します。ただし、notはその破損の修正に役立ちます。ハッシュは、エラー検出のみを提供し、修正は提供しません。
これは一般的に「整合性」が意味するものです。データの不正な/意図しない操作をdetectする可能性であり、それを防止または修正する可能性ではありません。
一般に、いくつかの理由から、RAID1とバックアップ（ZFSスナップショットなどで実装されている可能性がありますが、RAID1 +スナップショットのZFSセマンティクスに精通していません）が必要です。
ディスクに致命的な障害が発生した場合、データを復元するにはRAID1（または最近のバックアップ）が必要です。データの完全なコピー（RAID1）がない限り、エラーの修正はディスク全体の障害を修正できません。短いダウンタイムの場合、基本的にRAID1が必要です。
リポジトリの一部または全体を誤って削除した場合、バックアップが必要です（RAID1は、すべてのデバイスへの変更をすぐに反映するため、保護されません）
2つのディスクのみを備えたブロックレベルのRAID1（LVMなどを使用）は、データのサイレント減衰から保護しますがnot：RAIDコントローラーは、2つのディスクのどちらが正しいデータ。そのためには、ファイルのチェックサムなどの追加情報が必要です。ここでZSFとbtrfsのチェックサムが使用されます。これらを使用できます（これらの場合にareが使用されていると言うのではなく、ZFSまたはbtrfsがどのように処理するかわかりません） 2つのディスクのどちらが正しいデータを保持しているかを区別するために）。
ビット腐敗を防ぐ
いいえ、それはしません、まったく意味がありません。 gitによって導入されたRAIDのような冗長性はありません。あなたの.gitディレクトリの中のファイルが少し腐敗しているなら、いつものようにものを失うでしょう。
ビット腐敗を防ぐ？
Yyyy ...いや。それは発生するビット - 腐敗を助けませんが、それはビット - 腐敗を検出するのを助けます。しかし、通常の使用では、それはそれ自身のアカウントでは行われません（明らかに、オブジェクトをチェックアウトするときなどに行われますが、履歴用ではありません）。コンテンツからハッシュを再計算し、それらを実際のハッシュと比較するには、cronジョブを作成する必要があります。 gitハッシュは文字通り単にコンテンツハッシュであるため、そうするのはかなり簡単です。それらを再計算するのは簡単でgit fsckはそうします。しかし、それがビットの腐敗を検出した場合、それに対してそれができることは特にありません。特に、大きなチャンクは自動的に圧縮されるので、大きなオブジェクトのビットが反転されると、チャンク全体が失われる可能性があります。