40

Я прочитал, что ZFS и Btrfs используют контрольные суммы для предотвращения деградации данных, и я прочитал, что Git обладает целостностью благодаря хешированию практически всего с каждым коммитом.

Я собирался использовать сервер Git на сетевом хранилище Linux с Btrfs RAID 1 для хранения, но если Git обладает целостностью, я думаю, что в этом нет необходимости (по крайней мере, если все, что мне нужно, - это предотвращение деградации данных).

Вопрос: Таким образом, целостность Git, хотя хэширование по существу всего с каждым коммитом, предотвращает или помогает против бит-гнили?

3 ответа3

62

Хэширование Git происходит только во время создания коммитов, и с этого момента хэши используются для идентификации коммитов. Это никоим образом не гарантирует целостность файлов. Git-репозитории могут быть повреждены и потерять данные. На самом деле, git имеет встроенную команду для обнаружения такого рода потерь, git fsck, но, как сказано в документации, вы несете ответственность за восстановление любых поврежденных данных из резервных копий.

16

Зависит от того, что вы подразумеваете под "предотвратить".

(Прежде всего, bit-rot - это термин с несколькими определениями. Этот вопрос не о том, что код становится неработоспособным из-за отсутствия обслуживания.)

Если вы подразумеваете под "предотвращением" то, что он, скорее всего, обнаружит повреждение путем распада битов, да, это сработает. Однако это не поможет исправить это повреждение: хэши обеспечивают только обнаружение ошибок , а не исправление.

Обычно это означает "целостность": возможность обнаружения несанкционированных / непреднамеренных манипуляций с данными, а не возможность их предотвращения или исправления.

Как правило, вы все еще хотели бы иметь RAID1 вместе с резервными копиями (возможно, реализованными со снимками ZFS или аналогичными, я не знаком с семантикой ZFS на снимках RAID1 +) по нескольким причинам:

  • если диск выходит из строя со смертельным исходом, вам нужен RAID1 (или недавняя резервная копия) для восстановления ваших данных; никакое исправление ошибок не может исправить неисправность всего диска, если на нем нет полной копии данных (RAID1). Для кратковременного простоя у вас должен быть RAID1.

  • если вы случайно удалили части или весь репозиторий, вам нужна резервная копия (RAID1 не защищает вас, поскольку он сразу же отражает изменения на всех устройствах)

RAID1 уровня блока (например, через LVM или аналогичный), содержащий только два диска, сам по себе не защитит вас от тихого разрушения данных: контроллер RAID не может знать, какой из двух дисков содержит правильные данные. Для этого вам нужна дополнительная информация, например, контрольная сумма для файлов. Это где ZSF и Btrfs контрольные суммы бывают: они могут быть использованы (что не означает , что они используются в этих случаях, я не знаю , как ZFS или Btrfs обрабатывать вещи есть) , чтобы определить , какой из двух дисков имеет правильные данные.

1

предотвратить гниение

Нет, совсем нет. В git нет никакой избыточности, подобной RAID. Если файлы в вашем каталоге .git страдают от бит-гнили, вы потеряете все как обычно.

помочь против гниения?

Ыыыо ... нет. Это не помогает против возникновения гниения, но помогает обнаружить гниль. Но ни в коем случае при обычном использовании он не делает этого за свой счет (что, очевидно, происходит, когда вы проверяете некоторые объекты и т.д., Но не для своей истории). Вам нужно будет создать задания cron, чтобы пересчитать хэши из содержимого и сравнить их с реальными хешами. Это довольно тривиально, поскольку git хэши - это просто хеши контента, тривиально их пересчитать, а git fsck сделает это за вас. Но когда он обнаруживает гниль, он ничего не может сделать против него. В частности, поскольку более крупные фрагменты автоматически сжимаются, вы, скорее всего, понесете общую потерю фрагментов, если перевернуть бит в более крупном объекте.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .