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

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?

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:

• O cache do controlador RAID é RAM. Se não for suportado por uma bateria ou alguma tecnologia similar, você poderá perder uma quantidade significativa de dados.
• Alguns discos não desativam seus caches de write-back quando solicitados . É mais provável que isso ocorra com unidades de desktop baratas do que com unidades de servidor projetadas para RAIDs.

* 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 .