Apakah Git mencegah degradasi data


40

Saya membaca bahwa ZFS dan Btrf menggunakan checksum untuk mencegah degradasi data dan saya membaca bahwa Git memiliki integritas melalui hashing pada dasarnya segala sesuatu dengan setiap commit.

Saya akan menggunakan server Git pada Linux NAS dengan Btrfs RAID 1 untuk penyimpanan, tetapi jika Git memiliki integritas saya kira ini tidak perlu (setidaknya tidak jika mencegah degradasi data yang saya inginkan).

Pertanyaan: Jadi, apakah integritas Git meskipun dengan hashing dasarnya semuanya dengan masing-masing komit mencegah atau membantu melawan bit-rot?



3
Dan waspadalah terhadap klon lokal, git mencoba menggunakan tautan keras ketika Anda membuat klon di sistem file yang sama. Itu membuat kloning luar biasa cepat, tetapi jika satu objek rusak kedua klon rusak.
allo

Perhatikan bahwa jika korupsi hanya terjadi pada beberapa objek kuno pada mesin yang diberikan, objek-objek tersebut lebih mungkin untuk hadir pada klon lain dari repo, sedangkan (lebih sedikit) file yang lebih baru mungkin masih dapat digunakan. Saya tidak tahu bagaimana ini terintegrasi dengan file paket.
o11c

Jawaban:


61

Hashing Git hanya terjadi pada saat komit dibuat, dan dari sana hash digunakan untuk mengidentifikasi komit. Ini sama sekali tidak menjamin integritas file. Repositori Git dapat rusak dan kehilangan data. Sebenarnya, git memiliki perintah bawaan untuk mendeteksi kehilangan semacam ini, git fsck , tetapi seperti yang dikatakan dalam dokumentasi, Anda bertanggung jawab untuk memulihkan data yang rusak dari cadangan.


4
Mengapa fsckselalu terlihat seperti kata yang buruk bagi saya ... Saya kira jika muncul positif dan Anda tidak memiliki cadangan yang mungkin sesuai;)
CAD97

7
@ CAD97 Programmer dikenal untuk permainan kata-kata yang relatif timpang ini. Ini cukup umum sebenarnya ... Dari atas kepalaku, Anda memiliki hal-hal seperti sh (shell), bsh (Bourne shell), dan kemudian bash (Bourne lagi shell) ... yang terakhir menjadi pun yang lemah ...
Nelson

1
@Nelson jangan lupa ikan
user253751

@ CAD97 Sialan, nama git itu sendiri dapat dianggap seperti itu ketika itu tidak berfungsi untuk Anda.
SGR

1
@ CAD97 - dan itu sebelum Anda menjalankannya dengan flag seperti fvcctk - karena - jika Anda menjalankannya seperti itu, data Anda mungkin sudah "fvcctk" ed. ;)
Joe

16

Tergantung pada apa yang Anda maksud dengan "mencegah".

(Pertama-tama, bit-busuk adalah istilah dengan banyak definisi. Pertanyaan ini bukan tentang kode yang tidak dapat dihapus karena kurangnya pemeliharaan .)

Jika Anda maksud dengan "mencegah" bahwa ia kemungkinan akan mendeteksi korupsi dengan peluruhan bit, ya, itu akan berhasil. Namun tidak akan membantu untuk memperbaiki korupsi itu: hash hanya menyediakan deteksi kesalahan , bukan koreksi .

Ini umumnya apa yang dimaksud dengan "integritas": Kemungkinan untuk mendeteksi manipulasi data yang tidak sah / tidak disengaja, bukan kemungkinan untuk mencegah atau memperbaikinya.

Anda umumnya masih menginginkan RAID1 bersama dengan cadangan (mungkin diimplementasikan dengan snapshot ZFS atau serupa, saya tidak akrab dengan semantik ZFS pada snapshot +1 RAID1 +), karena beberapa alasan:

  • jika disk gagal fatal, Anda perlu RAID1 (atau cadangan baru-baru ini) untuk memulihkan data Anda; tidak ada koreksi kesalahan yang dapat memperbaiki kesalahan seluruh disk, kecuali jika ia memiliki salinan lengkap data (RAID1). Untuk downtime singkat, Anda pada dasarnya harus memiliki RAID1.

  • jika Anda secara tidak sengaja menghapus bagian atau seluruh repositori, Anda memerlukan cadangan (RAID1 tidak melindungi Anda karena segera mencerminkan perubahan ke semua perangkat)

RAID1 tingkat blok (mis. Via LVM atau serupa) dengan hanya dua disk itu sendiri tidak akan melindungi Anda terhadap pembusukan data secara diam-diam: pengontrol RAID tidak dapat mengetahui yang mana dari dua disk yang menyimpan data yang benar. Anda memerlukan informasi tambahan untuk itu, seperti checksum atas file. Di sinilah ZSF dan btrfs checksum datang dalam: mereka dapat digunakan (yang bukan untuk mengatakan bahwa mereka yang digunakan dalam kasus ini, saya tidak tahu bagaimana ZFS atau btrfs menangani hal-hal di sana) untuk membedakan mana dari dua disk memegang data yang benar.


5
Tidak perlu pergi dengan mirroring jika Anda tidak mau. ZFS mendukung striping dengan nilai paritas 1, 2 atau 3 drive; dan mirroring dengan jumlah drive yang berubah-ubah (termasuk drive tunggal = tanpa redundansi). Penyimpanan massal utama saya adalah ZFS dengan enam drive dalam konfigurasi RAIDZ2, yang pada dasarnya adalah file level sistem RAID6 (striping dengan redundansi senilai dua drive). Ini dapat mendeteksi dan memulihkan dari kehilangan salah satu drive tersebut plus kesalahan yang tidak dapat diperbaiki pada satu drive lagi; atau hilangnya dua drive dan tidak ada kesalahan di tempat lain selama resilver; tanpa kehilangan data. Backup masih disarankan.
CVn

1

mencegah bit-rot

Tidak, sama sekali tidak. Tidak ada redundansi seperti RAID yang diperkenalkan oleh git. Jika file dalam .gitdirektori Anda mengalami bit-rot, Anda akan kehilangan barang seperti biasa.

membantu melawan bit-busuk?

Yyyy ... tidak. Ini tidak membantu melawan bit-rot yang terjadi, tetapi akan membantu mendeteksi bit-rot. Tetapi pada saat penggunaan normal tidak melakukannya dengan akun sendiri (baik jelas itu terjadi ketika Anda memeriksa beberapa objek dan sebagainya, tetapi tidak untuk sejarah Anda). Anda harus membuat pekerjaan cron untuk menghitung ulang hash dari konten dan membandingkannya dengan hash yang sebenarnya. Sangat sepele untuk melakukannya, karena githash secara harfiah hanyalah hash konten, itu sepele untuk menghitung ulang mereka dan git fsckmelakukannya untuk Anda. Tetapi ketika mendeteksi bit-rot, tidak ada yang khusus yang dapat dilakukan untuk melawannya. Secara khusus, karena potongan yang lebih besar secara otomatis dikompresi, Anda mungkin akan mengalami kerugian chunk total jika sedikit benda yang lebih besar dibalik.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.