Eu li que o ZFS e o Btrfs usam somas de verificação para evitar degradação de dados e eu li que o Git tem integridade por meio de hashing essencialmente tudo com cada commit.
Eu usaria um servidor Git em um Linux NAS com Btrfs RAID 1 para armazenamento, mas se o Git tivesse integridade eu acho que isso não seria necessário (pelo menos não se impedir a degradação de dados é tudo que eu quero).
Pergunta: O mesmo acontece com a integridade do Git, apesar de praticamente tudo com cada commit prevenir ou ajudar contra a podridão de bits?
O hash do Git só acontece no momento em que os commits são criados e, a partir daí, os hashes são usados para identificar os commits. Isso não garante a integridade dos arquivos. Os repositórios do Git podem se corromper e perder dados. Na verdade, o git tem um comando interno para detectar esse tipo de perda, git fsck , mas como a documentação diz que você é responsável por restaurar os dados corrompidos dos backups.
Depende do que você quer dizer com "evitar".
(Primeiro de tudo, bit-rot é um termo com várias definições. Esta questão é não sobre code se tornando irrecuperável devido à falta de manutenção .)
Se você quer dizer "previna" que ele provavelmente detectará corrupção pelo decaimento de bits, sim, isso funcionará. No entanto, não ajudará a corrigir essa corrupção: os hashes só fornecem detecção de erro, não correção .
Isto é geralmente o que se entende por "integridade": A possibilidade de detectar manipulação não autorizada / não intencional de dados, não a possibilidade de prevenir ou corrigir isso.
Geralmente, você ainda deseja um RAID1 junto com backups (possivelmente implementados com instantâneos do ZFS ou semelhantes, não estou familiarizado com a semântica do ZFS em instantâneos RAID1 +), por diversos motivos:
se um disco falhar fatalmente, você precisará de um RAID1 (ou um backup recente) para restaurar seus dados; nenhuma correção de erro pode corrigir a falha de todo um disco, a menos que tenha uma cópia completa dos dados (RAID1). Por um curto período de inatividade, você essencialmente deve ter o RAID1.
se você acidentalmente excluir partes ou todo o repositório, precisará de um backup (o RAID1 não protege você, pois reflete imediatamente a alteração em todos os dispositivos)
RAID1 em nível de bloco (por exemplo, via LVM ou similar) com apenas dois discos em si não protege você contra a decadência silenciosa de dados: o controlador RAID não pode saber qual dos dois discos mantém a dados corretos. Você precisa de informações adicionais para isso, como uma soma de verificação dos arquivos. É aí que entram as somas de verificação ZSF e btrfs: elas podem ser usadas (o que não quer dizer que são usadas nesses casos, eu não sei como o ZFS ou o btrfs lida com as coisas lá) distinguir qual dos dois discos contém os dados corretos.
prevent bit-rot
Não, isso não acontece de forma alguma. Não há redundância semelhante a RAID introduzida pelo git. Se os arquivos no diretório .git sofrerem podridão, você perderá as coisas como sempre.
help against bit-rot?
Yyyy ... não. Isso não ajuda na ocorrência de podridão de bits, mas ajudará a detectar a podridão de bits. Mas em nenhum momento durante o uso normal ele faz isso por conta própria (bem, obviamente, quando você verifica alguns objetos e assim por diante, mas não para o seu histórico). Você teria que criar tarefas agendadas para recalcular os hashes do conteúdo e compará-los aos hashes reais. É bastante trivial fazê-lo, pois git hashes são literalmente simplesmente hashes de conteúdo, é trivial recalculá-los e git fsck faz isso para você. Mas quando detecta bit-rot, não há nada em particular que possa fazer contra isso. Especificamente, como pedaços maiores são automaticamente compactados, você provavelmente incorrerá em perda total de fragmentos se um bit em um objeto maior for invertido.
Tags git btrfs zfs data-integrity