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

Question

Eu estou tentando fazer cow-cópias de alguns arquivos / diretórios, mas das várias maneiras que eu conheço, todos parecem sub-ótimos.

Por exemplo, o btrfs pode, com o uso de cp --reflink=auto , gerar rapidamente cópias de arquivos.

O que tentei:

1. Links simbólicos: não é bom. Arquivo renomeado, link quebrado.
2. Hardlinks: melhor, mas ainda não é bom. As alterações em um arquivo alteram o outro e não quero necessariamente que o outro arquivo seja alterado.
3. Crie um instantâneo do conjunto de dados e, em seguida, clone o instantâneo: Isso pode funcionar, mas não é bem assim. Muitas vezes não estou procurando uma cópia do conjunto de dados inteiro ou que as cópias funcionem como outro conjunto de dados. Depois, há os relacionamentos pai / filho entre o clone / instantâneo / original, que, segundo entendo, são difíceis, se não impossíveis, de serem quebrados.
4. Usando zfs send/receive e habilitado, copie o conjunto de dados para um novo conjunto de dados: Isso evita o relacionamento pai / filho de usar um clone, mas ainda cria desnecessariamente outro conjunto de dados e ainda sofre com a lentidão envolvida nos arquivos para ser lido 100% e os blocos referenciados novamente em vez de escritos.
5. Copie arquivos e permita que a dedup faça seu trabalho: Isso funciona, mas é lento porque o (s) arquivo (s) precisa (m) ser 100% lido e, em seguida, os blocos referenciados novamente, em vez de serem escritos.

A lentidão do envio / recebimento do zfs e da cópia ou ressincronização física é ainda mais exacerbada porque a maioria das coisas é armazenada compactada e precisa ser descompactada durante a leitura, depois compactada antes de a dedução entrar para fazer referência a blocos duplicados.

Em toda a minha pesquisa, não consegui encontrar nada remotamente parecido com a simplicidade do --reflink no btrfs.

Existe uma maneira de criar cópias cow no ZFS? Ou é "fisicamente" copiando e deixando dedup fazer o seu trabalho a única opção real?

    

Answer 1

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

Sugiro strongmente evitar o uso de dedup, a menos que você tenha verificado se funciona bem com o seu ambiente exato. Eu tenho experiência pessoal com dedup trabalhando muito bem até que mais um usuário ou VM store seja movido, e então ele cai de um cliff de performance e causa muitos problemas. Só porque parece que está funcionando muito bem com seus primeiros dez usuários, sua máquina pode cair quando você adiciona o décimo primeiro (ou décimo segundo, ou décimo terceiro, ou qualquer outro). Se você quiser seguir esse caminho, certifique-se de ter um ambiente de teste que imite exatamente seu ambiente de produção e que ele funcione bem nesse ambiente.

De volta à opção 3, você precisará configurar um conjunto de dados específico para armazenar cada uma das árvores do sistema de arquivos que deseja gerenciar dessa maneira. Depois de configurá-lo e preenchê-lo inicialmente, tire seus instantâneos (um por conjunto de dados que será um pouco diferente) e promova os 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. Eu encontrei essa referência para alguém que usa clones com eficiência: link

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

    

Answer 2

A opção 5 é a melhor.

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

No que diz respeito 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 o seu dispositivo de bloco (mesmo se estiver usando SSDs). Apenas para alguns números de exemplo, digamos que são necessários 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 concluirá sua tarefa em 3 segundos e, em seguida, passará os próximos 7 segundos aguardando no disco. O disco, entretanto, passou a mesma quantidade de tempo lendo esses dois blocos (20 segundos), independentemente de os blocos estarem ou não comprimidos.

Da mesma forma, ao escrever, apenas o primeiro bloco é atrasado. A CPU comprime / 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 subseqüentes. A CPU vai mastigar blocos muito mais rápido do que o disco pode escrevê-los, então não é um problema. (Sim, é mais complexo que isso, mas essa é a essência.)

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