Czy Git zapobiega degradacji danych

Czytam, że ZFS i Btrfs używają sum kontrolnych, aby zapobiec degradacji danych, i czytam, że Git ma integralność poprzez mieszanie zasadniczo wszystkiego przy każdym zatwierdzeniu.

Zamierzałem użyć serwera Git na Linux NAS z Btrfs RAID 1 do przechowywania, ale jeśli Git ma integralność, myślę, że nie byłoby to konieczne (przynajmniej jeśli zapobieganie degradacji danych jest wszystkim, czego chcę).

Pytanie: Czy zatem integralność Gita ma w zasadzie wszystko za każdym razem, gdy każde zatwierdzenie zapobiega lub pomaga w zwalczaniu zepsucia bitowego?

Haszowanie Gita odbywa się tylko w momencie tworzenia zatwierdzeń, a stamtąd skróty są używane do identyfikowania zatwierdzeń. W żaden sposób nie zapewnia to integralności plików. Repozytorium Git może ulec uszkodzeniu i utracić dane. W rzeczywistości git ma wbudowane polecenie wykrywania tego rodzaju strat, git fsck , ale jak mówi dokumentacja, jesteś odpowiedzialny za przywrócenie uszkodzonych danych z kopii zapasowych.

Zależy, co rozumiesz przez „zapobieganie”.

(Przede wszystkim bit-rot jest terminem z wieloma definicjami. To pytanie nie dotyczy tego, że kod przestanie być uruchamiany z powodu braku konserwacji ).

Jeśli masz na myśli „zapobieganie”, że najprawdopodobniej wykryje ono uszkodzenie przez rozpad bitów, tak, to zadziała. Jednak to nie pomoże naprawić tego uszkodzenia: skróty zapewniają jedynie wykrywanie błędów , a nie korekcję .

Zasadniczo rozumie się przez to „integralność”: możliwość wykrycia nieautoryzowanej / niezamierzonej manipulacji danymi, a nie możliwość jej zapobiegania lub korygowania.

Zasadniczo nadal chciałbyś RAID1 razem z kopiami zapasowymi (prawdopodobnie zaimplementowanymi z migawkami ZFS lub podobnymi, nie znam semantyki ZFS na migawkach RAID1 +) z kilku powodów:

• jeśli dysk ulegnie awarii, albo potrzebujesz RAID1 (lub ostatniej kopii zapasowej), aby przywrócić dane; żadna korekcja błędów nie może naprawić awarii całego dysku, chyba że ma on pełną kopię danych (RAID1). W przypadku krótkiego przestoju zasadniczo musisz mieć RAID1.

• jeśli przypadkowo usuniesz części lub całe repozytorium, potrzebujesz kopii zapasowej (RAID1 nie chroni cię, ponieważ natychmiast odzwierciedla zmianę na wszystkich urządzeniach)

Blokowy poziom RAID1 (np. Przez LVM lub podobny) z tylko dwoma dyskami sam w sobie nie ochroni cię przed cichym rozpadem danych: kontroler RAID nie może wiedzieć, który z dwóch dysków zawiera prawidłowe dane. Potrzebujesz do tego dodatkowych informacji, takich jak suma kontrolna nad plikami. Tutaj przychodzą sumy kontrolne ZSF i btrfs: można ich użyć (co nie znaczy, że są one używane w tych przypadkach, nie wiem, jak ZFS lub btrfs tam obsługują), aby rozróżnić, który z dwóch dysków ma miejsce poprawne dane.

zapobiec gniciu bitów

Nie, wcale tak nie jest. Git nie wprowadza redundancji podobnej do RAID. Jeśli pliki w twoim .gitkatalogu ulegną zgniliznom bitów, stracisz rzeczy jak zwykle.

pomoc przeciwko zgniliznie bitów?

Yyyy ... nie. Nie pomaga w walce z gniciem bitowym, ale pomaga wykryć gnicie bitowe. Ale w żadnym momencie podczas normalnego użytkowania nie robi tego z własnego konta (oczywiście, że dzieje się tak, gdy sprawdzasz niektóre przedmioty i tak dalej, ale nie dla twojej historii). Będziesz musiał utworzyć zadania cron, aby ponownie obliczyć skróty z zawartości i porównać je z rzeczywistymi skrótami. Jest to dość trywialne, ponieważ githasze są dosłownie po prostu haszami treści, trywialne jest ich ponowne obliczenie i git fsckrobi to za Ciebie. Ale kiedy wykryje zgniliznę bitów, nic szczególnego nie może zrobić przeciwko niemu. W szczególności, ponieważ większe fragmenty są automatycznie kompresowane, najprawdopodobniej poniesiesz całkowitą utratę fragmentów, jeśli bit w większym obiekcie zostanie odrzucony.