Forçar soma de verificação de atualização no zfs?

Recentemente, alterei a checksumpropriedade em um dos meus sistemas de arquivos zfs não duplicados para sha256de on(fletcher4) para suportar melhor o envio de steams de replicação duplicados, como neste comando zfs send -DR -I _starting-snaphot_ _ending-snapshot_.

No entanto, a página de manual do zfs tem a dizer sobre send -D:

Esse sinalizador pode ser usado independentemente da propriedade de deduplicação do conjunto de dados, mas o desempenho será muito melhor se o sistema de arquivos usar uma soma de verificação com capacidade para deduplicação (por exemplo, sha256).

A página de manual do zfs também afirma isso sobre a checksumpropriedade:

A alteração dessa propriedade afeta apenas os dados recém-gravados.

Não desejo confiar em fletcher4. A desvantagem é que, diferentemente do SHA256, o fletcher4 não é uma função de hash pseudo-aleatória e, portanto, não se pode confiar que não colidam. Portanto, é adequado apenas para desduplicação quando combinado com a opção 'verificar', que detecta e resolve colisões de hash.

Como posso atualizar as somas de verificação do sistema de arquivos, de preferência sem desligar o sistema?

zfs zfsonlinux

— 84104
fonte

Para alterar as propriedades (compactação, desduplicação ou soma de verificação) dos dados já gravados, a abordagem do zfs é executar os dados por uma zfs send | zfs receivesequência. Obviamente, você não precisa para offline do sistema para isso, mas você vai precisar

recursos suficientes no seu zpool / no sistema para armazenar duas cópias deduplicadas do conjunto de dados em questão
tempo de inatividade do conjunto de dados, pois você precisaria destruí-lo ou renomeá-lo no procedimento
tempo e paciência suficientes para a operação ser concluída

Como você já está usando a desduplicação para o zpool, executar a zfs send | zfs receivecom o destino no mesmo pool que a origem usaria apenas o espaço necessário para os blocos de metadados recém-gravados. Mas esteja preparado para a cópia demorar um pouco - a desduplicação pode ser muito lenta, especialmente se você não tiver RAM suficiente para armazenar toda a tabela de desduplicação na RAM.

Obviamente, você precisaria interromper todas as operações de gravação para criar a cópia final e autorizada do conjunto de dados, mas poderia minimizar o tempo de inatividade copiando primeiro um instantâneo, interrompendo todas as gravações e fazendo incremental zfs send -i | zfs receivecomo a etapa final.

— o wabbit
fonte

Não está claro para mim que zfs receiveatualize os metadados de um sistema de arquivos. Parece-me que seria muito mais rápido se simplesmente pegasse os metadados como estão. No entanto, isso pode ser impossível devido à natureza do nível do bloco de soma de verificação, e não do arquivo. Nesse caso zfs send | zfs receive, formaria uma base aceitável para uma solução.

— 84104 05/10

zfs send | O zfs recv alterará efetivamente todos os metadados (opção de compactação, opção de soma de verificação, opção de redução de redundância). O zfs send está criando um objeto que você ingere usando o zfs recv, que o grava praticamente como se fossem novos dados. No entanto - acho que você pode estar sob um equívoco sobre o zfs send | recv com relação à deduplicação. O zfs send -D tenta deduplicar os dados / dentro do próprio fluxo /, não mantém a deduplicação existente dos dados do conjunto de dados de origem. É por isso que não há exigência de que o lado da recv também tenha a desduplicação ativada no conjunto de dados de destino.

— Nex7

Para explicar melhor - atualmente não há como zfs enviar dados desduplicados | recv de maneira que tudo o que atravessa a conexão seja uma única cópia dos dados desduplicados e das entradas da tabela de desduplicação associadas. Nem mesmo se a origem e o destino estiverem sincronizados e você não estiver enviando nada além de um instantâneo incremental. O ZFS ainda aumenta o tamanho dos dados de envio se os dados contidos nele forem desduplicáveis / dentro do escopo do próprio fluxo /. Você pode ter dados que são facilmente deduplicados no DDT da POOL, mas como um pequeno objeto de envio, é completamente não deduplicável.

— Nex7