O BTRFS garante a consistência dos dados em falta de energia?

11

Como o ZFS declara exclusivamente ,O ZFS é declarado invulnerável O ZFS aceita que possa estar vulnerável a falhas de energia.

Não consegui encontrar essa declaração para o BTRFS. É (ou projetado / planejado para ser) durável entre quedas de energia?

ceremcem
fonte
Leia de novo. "Se o seu pool estiver danificado devido a falha de hardware ou falta de energia, consulte Reparando os danos em todo o pool de armazenamento do ZFS." (..) Tente recuperar o pool usando o zpool clear -F comando
Michael D.
Então você diz "O ZFS não garante a consistência dos dados, apenas tenta se recuperar"?
ceremcem
Sim. Existem vários caches para lidar, um cache interno de discos rígidos, caches / buffers de SO. Em algum momento, existe um syncou um flushque grava caches no disco, ou não durante uma queda de energia, que os dados serão perdidos. O ZFS pode funcionar perfeitamente se o disco rígido estiver íntegro e não houver falta de energia (ou um no- break estiver conectado ao computador para desligar corretamente em uma queda de energia). O que você não pode dizer sobre o FAT32 mais ou menos.
Michael D.
2
A perda de dados não é uma preocupação, pois é uma consequência natural quando ocorre uma perda de energia, mas a consistência dos dados é uma preocupação no meu caso. Um sistema de arquivos pode perder dados em condições tão extremas, mas não deve causar dados inconsistentes no disco. Eu preciso do recurso de instantâneos contínuos, então continuarei com o BTRFS. NILFS2 é a opção mais próxima no meu caso.
ceremcem
1
Fiz a pergunta no #btrfs IRC, eles disseram should be ok if your hw isn't "buggy"onde não significa "buggy" your hw has correct flush/barrier semantics. Eu publiquei um link para esta pergunta no IRC, espero que alguém leve algum tempo para elaborar; mas por enquanto é isso.
Hi-Angel

Respostas:

5

Fiz a pergunta no #btrfs IRC, eles disseram should be ok if your hw isn't "buggy"onde não significa "buggy" your hw has correct flush/barrier semantics.

TL; DR: Isso significa que o btrfs está protegido contra corrupção de dados devido à perda de energia de maneira semelhante ao ZFS.

Aqui está o porquê: A idéia geral por trás do ZFS e do btrfs é semelhante. Ambos usam árvores Merkle como uma estrutura de dados . As gravações podem exigir a atualização de vários blocos no (s) disco (s). O sistema de arquivos está lidando com isso gravando os novos dados em blocos vazios (mesmo que um arquivo existente esteja sendo modificado, portanto, não é necessário modificar os blocos que refletem o estado antigo) e construindo uma nova árvore atualizada. Depois que todo o trabalho pesado é feito e os dados + a árvore atualizada foram gravados no disco, o ponteiro do cabeçalho é atualizado para a nova árvore, tornando visível a alteração.

Aqui está como as coisas devem se comportar ao gravar em um arquivo:

  1. Grave dados para liberar blocos no disco.
  2. Faça uma cópia da árvore Merkle *, atualize-a de acordo com as alterações escritas em (1).
  3. Peça ao hardware para liberar os dados no disco - o hardware grava todos os dados pendentes.
  4. Atualize o ponteiro da cabeça para a nova árvore Merkle.
  5. Blocos antigos gratuitos que não são mais necessários.

Se a energia for perdida após (4), a transação será concluída. Se a energia for perdida durante as etapas (1) a (3), o sistema de arquivos apresentará o estado antigo (os dados gravados na etapa (1) são perdidos, mas o sistema de arquivos é consistente). Observe que não há necessidade de verificar se há erros no sistema de arquivos, o que significa que o sistema está disponível imediatamente, o que é uma grande vantagem (a verificação de sistemas de arquivos grandes pode levar muito tempo!).

Aqui está um exemplo de como as coisas podem dar errado com o hardware "buggy":

  1. Grave dados para liberar blocos no disco.
  2. Faça uma cópia da árvore Merkle *, atualize-a de acordo com as alterações escritas em (1).
  3. Peça ao hardware para descarregar os dados para o disco - o hardware confirma a conclusão, mas não libera todo o caminho (por exemplo, os dados podem permanecer no cache de write-back do disco).
  4. Atualize o ponteiro da cabeça para a nova árvore Merkle. Esses dados são gravados no disco antes de outros dados pendentes (por exemplo, porque a cabeça do disco está no local correto).
  5. Os dados gravados nas etapas (1) e (2) são gravados no disco.
  6. Blocos antigos gratuitos que não são mais necessários.

O sistema de arquivos se tornará inconsistente se perder energia entre (4) e (5) ou ao executar a etapa (5). Como conseqüência, a árvore Merkle e / ou os dados podem ser gravados apenas parcialmente, tornando o sistema de arquivos inconsistente.

Na prática, você deve ter um cuidado especial ao usar os controladores RAID . Eles geralmente desabilitam os caches de write-back no disco e usam seu próprio cache de write-back. Existem duas maneiras comuns de as coisas darem errado aqui:

* Estou simplificando as coisas aqui. Na verdade, não é necessário copiar a árvore inteira. Apenas as partes que foram alteradas precisam ser adicionadas - as partes restantes podem ser compartilhadas entre a árvore antiga e a nova .

Martin
fonte
Obrigado por esta boa explicação. No entanto, é necessária citação para todas as reivindicações, incluindo a conversa no IRC. Então sua resposta será aceita.
ceremcem 22/05/19
Em relação aos logs do IRC, eu estava me referindo ao comentário do @ Hi-Angel aqui. Talvez ele possa fornecer uma referência? Eu adicionei mais algumas referências às outras partes, no entanto.
Martin
O BTRFS não usa árvores Merkle, ele usa árvores B (daí 'B-TRee FileSystem'), e seus exemplos de falhas exigem que as barreiras de gravação não sejam implementadas adequadamente pelo hardware (o que é realmente um caso incomum atualmente) . Caso contrário, boa resposta.
Austin Hemmelgarn
As árvores usadas pelo btrfs são, na verdade, ambas as árvores B (essa propriedade é sobre a "forma" da árvore e o fato de serem auto balanceadas) e as árvores hash / Merkle (as folhas contêm o hash de alguns dados, os nós contêm o hash de seus filhos, portanto, cada alteração se propaga até a raiz). Ser capaz de verificar esses hashes é o que permite que o btrfs e o ZFS detectem dados corrompidos (e os leiam de outro disco, se usados ​​no modo "espelhamento").
Martin