Existe uma maneira de criar cópias de vaca no ZFS?

Estou tentando fazer cópias de vaca de alguns arquivos / diretórios, mas, das várias maneiras que conheço, tudo parece subótimo.

Por exemplo, o btrfs pode, com o uso de cp --reflink=autogerar rapidamente cópias de vaca dos arquivos.

O que eu tentei:

1. Links simbólicos: Não é bom. Arquivo renomeado, link quebrado.
2. Hardlinks: Melhor, mas ainda não é bom. Mudanças em um arquivo mudarão no outro, e eu não quero necessariamente que o outro arquivo seja alterado.
3. Crie uma captura instantânea do conjunto de dados e clone a captura instantânea: Isso pode funcionar, mas não é bom. Frequentemente, não estou procurando uma cópia de todo o conjunto de dados ou para que as cópias funcionem como outro conjunto de dados. Depois, há os relacionamentos pai / filho entre o clone / instantâneo / original, que, pelo que entendi, são difíceis, se não impossíveis de quebrar.
4. O uso zfs send/receivee a desduplicação ativada replicam o conjunto de dados para um novo conjunto de dados: isso evita o relacionamento pai / filho de usar um clone, mas ainda desnecessariamente cria outro conjunto de dados e ainda sofre com a lentidão envolvida nos arquivos que precisam ser lidos 100% e os blocos referenciados novamente em vez de escritos.
5. Copie arquivos e deixe que a desduplicação faça seu trabalho: isso funciona, mas é lento porque os arquivos precisam ser 100% lidos e os blocos referenciados novamente em vez de serem gravados.

A lentidão do envio / recebimento de zfs e a cópia ou rsyncing fisicamente são ainda mais exacerbadas porque a maioria das coisas é armazenada compactada e precisa ser descomprimida durante a leitura e depois comprimida antes da dedução entrar em referência para blocos duplicados.

Em todas as minhas pesquisas, não consegui encontrar nada remotamente parecido com a simplicidade de --reflink no btrfs.

Então, existe uma maneira de criar cópias de vaca no ZFS? Ou copiar "fisicamente" e deixar que a desduplicação faça seu trabalho são a única opção real?

Acho que a opção 3, como você descreveu acima, é provavelmente a sua melhor aposta. O maior problema com o que você deseja é que o ZFS realmente lide apenas com essa cópia na gravação no nível do conjunto de dados / captura instantânea.

Eu sugeriria fortemente evitar o uso de desduplicação, a menos que você tenha verificado que ele funciona bem com seu ambiente exato. Tenho experiência pessoal com a desduplicação, trabalhando muito bem até que mais um usuário ou loja de VM seja transferido e, em seguida, cai de um penhasco de desempenho e causa muitos problemas. Só porque parece que está funcionando muito bem com seus dez primeiros usuários, sua máquina pode cair quando você adiciona o décimo primeiro (ou décimo segundo, décimo terceiro, décimo terceiro ou qualquer outra coisa). Se você quiser seguir esse caminho, certifique-se de ter um ambiente de teste que imite exatamente o ambiente de produção e que funcione bem nesse ambiente.

De volta à opção 3, será necessário configurar um conjunto de dados específico para armazenar cada uma das árvores do sistema de arquivos que você deseja gerenciar dessa maneira. Depois de configurá-lo e preenchê-lo inicialmente, tire seus instantâneos (um por conjunto de dados que diferem um pouco) e promova-o em clones. Nunca toque no conjunto de dados original novamente.

Sim, esta solução tem problemas. Não estou dizendo que não, mas dadas as restrições do ZFS, ainda é provavelmente o melhor. Encontrei essa referência para alguém que usa clones de maneira eficaz: http://thegreyblog.blogspot.com/2009/05/sparing-disk-space-with-zfs-clones.html

Eu não estou muito familiarizado com o btrfs, mas se ele suporta as opções desejadas, você considerou configurar um servidor separado apenas para suportar esses conjuntos de dados, usando Linux e btrfs nesse servidor?

A opção 5 é a melhor.

No que diz respeito aos conjuntos de dados pai / filho na opção 3, você pode promover um clone e ele não será mais filho do conjunto de dados clonado. Ainda não vai usar blocos extras. Edit: Observou que isso apenas reverte o relacionamento pai / filho, não o destrói.

Com relação a coisas que estão sendo compactadas / criptografadas e que diminuem a velocidade da cópia, isso é completamente falso. Seu processador é muito mais rápido do que seu dispositivo de bloco (mesmo se estiver usando SSDs). Apenas para alguns números de exemplo, digamos que leva 10 segundos para ler um bloco, mas leva apenas um segundo para descompactá-lo e 2 segundos para descriptografá-lo. O bloco 1 é lido em 10 segundos e enviado para a CPU. A CPU começa a descompactar e descriptografar enquanto o disco começa a ler o bloco 2. A CPU conclui sua tarefa em 3 segundos e depois passa os próximos 7 segundos aguardando no disco. Enquanto isso, o disco passou exatamente a mesma quantidade de tempo lendo esses dois blocos (20 segundos), independentemente de os blocos estarem compactados ou não.

Da mesma forma, ao escrever, apenas o primeiro bloco está atrasado. A CPU compacta / criptografa o bloco 1 e o envia para o disco. Enquanto o disco estiver gravando o bloco 1, a CPU começará a compactar / criptografar os blocos subsequentes. A CPU mastiga blocos muito mais rapidamente do que o disco pode gravá-los, portanto não é um problema. (Sim, é mais complexo que isso, mas essa é a essência.)

Desculpe pela excessivamente longa explicação de um ponto menor na sua pergunta, mas eu queria esclarecer esse equívoco.