Como determinar se algum dos meus instantâneos do ZFS é realmente redundante e seguro para excluir sem perda de dados?

Question

Estou usando o FreeBSD 11.1 e a saída de zfs list -t snap -r poolname mostra um grande número de meus instantâneos com "0" em "USED". Eu li sobre como o ZFS conta com espaço, então eu entendo o básico, e eles sugerem para mim que

1. "0" significa que o instantâneo não usa espaço em disco, no sentido de que a exclusão não recupera espaço em disco.
2. Se um arquivo estiver presente em 2 instantâneos, isso não melhorará a redundância nesse arquivo, pois tudo isso significa que existem vários ponteiros (referências) para esse arquivo (ou, mais exatamente, para a série de blocos que compõem esse arquivo), não existem cópias extras.

Portanto, a lógica sugere que qualquer snapshot com USED = 0 provavelmente seja uma cópia idêntica do snapshot anterior do objeto rhat, e seguro excluir se você não quiser manter snapshots para os quais nada mudou a partir do snapshot anterior, e nenhuma redundância é perdida ao fazer isso .

Estou muito ligado a não excluir dados antigos ou reduzir a redundância se isso reduzir a segurança dos dados, e posso pensar em pelo menos alguns possíveis motivos para que isso não seja tão simples assim:

• Os valores USUAL da captura instantânea podem mudar quando outros instantâneos são destruídos, mas a presença de tamanho zero deve sugerir strongmente em praticamente qualquer uso normal, que existe outro snap de tamanho diferente de zero que é idêntico. Mas "sugere strongmente" não significa "implausível que não é assim", e zero significa que todos os blocos existem não que eles sejam organizados de forma idêntica e os arquivos são os mesmos. Há algum caso em que não seja necessariamente seguro eliminar "off-hand" todos os snaps de tamanho zero?

• Como exemplo disso, imagine que (1) criamos um arquivo de 100MB e capturamos o conjunto, em seguida (2) criamos dois outros arquivos de 75MB contendo o primeiro e último 75% do arquivo de 100MB, respectivamente, e o arquivo de 100 MB e, em seguida, o instantâneo novamente. O segundo snapshot mostrará 0 espaço usado porque todos os blocos existem no snap anterior, mas os arquivos nesse snapshot são de fato exclusivos. Não consigo pensar em uma maneira de detectar isso porque a contabilização de espaço no ZFS não é baseada em arquivos. Talvez, com a dedup em uso e alguns tipos de arquivos que são anexados ou 'tail'ed, isso pode ser comum se for raro, não apenas um caso de borda patológica.

Então, não tenho certeza. Talvez o tamanho do snap seja um arenque vermelho e eu precise verificar outras propriedades.

Existem quaisquer circunstâncias não-triviais que se possa determinar com segurança e rapidez se um snapshot do ZFS é redundante (no sentido em que estou usando o termo), e que é seguro excluí-lo?

Ou há outra maneira melhor (rápida + eficaz) de dizer, de outras propriedades ou do ZFS ou o que quer que seja, se dois snaps sequenciais apontam para o mesmo ponto no tempo / número de sequência de gravação do pool no histórico do pool? confirmar categoricamente que eles fazem referência a dados idênticos)?

    

Answer 1

USED=0 é um indicador razoável para um instantâneo ser uma duplicata do anterior. No entanto, certifique-se de que ele seja realmente zero e não uma versão arredondada de zero (como 0,1 KB, arredondado para o KB mais próximo). Você pode usar o sinalizador -p ("parseable") para obter o número exato medido em bytes. Observe também que pode levar alguns segundos para que os números de contabilidade de espaço sejam atualizados depois que você criar um instantâneo.

Como você sugere, você também pode usar zfs diff para obter a mesma coisa. Isso tem o benefício adicional de dizer a você o que mudou.

O exemplo que você deu (onde os blocos são compartilhados entre os arquivos) só pode acontecer se você tiver a dedução ativada. Caso contrário, o ZFS ainda armazenaria várias cópias dos blocos e consideraria esse espaço apropriadamente. Mesmo com a dedup, ambos os métodos acima mostrarão diferenças - o instantâneo não ocuparia% zeroUSED espaço porque você precisaria de novos metadados para os dois arquivos (dois inodes mais os blocos indiretos apontando para os blocos deduidos; talvez outros também, e zfs diff mostrará +<filename> para os dois novos arquivos.

EDIT: A última maneira visível para o usuário que eu posso pensar em verificar isso é executando zfs send -nv (execução seca, detalhada) incrementalmente entre os instantâneos. Isso não gerará o fluxo de envio completo, mas poderá informar o que seria enviado, o que não deve ser nada se os dois instantâneos forem os mesmos.