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

Question

Estou tentando fazer cópias de alguns arquivos/diretórios, mas das várias maneiras que conheço, todas parecem abaixo do ideal.

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

O que eu 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 alterarão 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: isso pode funcionar, mas não muito bem. Freqüentemente, não procuro uma cópia de todo o conjunto de dados ou que as cópias funcionem como outro conjunto de dados. Depois, há os relacionamentos pai/filho entre clone/instantâneo/original, que, pelo que entendi, são difíceis, senão impossíveis de quebrar.
4. Usando zfs send/receive, e desduplicação habilitada, replique o conjunto de dados para um novo conjunto de dados: Isso evita os relacionamentos pai/filho do uso de um clone, mas ainda cria outro conjunto de dados desnecessariamente 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 os arquivos e deixe a desduplicação fazer 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 do zfs e da cópia física ou rsyncing é ainda mais exacerbada porque a maioria das coisas são armazenadas compactadas e precisam ser descompactadas durante a leitura e, em seguida, compactadas antes que a desduplicação entre em ação para fazer referência a 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 a desduplicação fazer seu trabalho é a única opção real?

Answer 1

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

Eu sugiro fortemente evitar o uso de desduplicação, a menos que você tenha verificado que funciona bem com seu ambiente exato. Tenho experiência pessoal com a desduplicação funcionando muito bem até que mais um usuário ou armazenamento de VM seja transferido, e então ele cai em um penhasco de desempenho 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ê adicionar 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 funcione bem nesse ambiente.

De volta à opção 3, você precisará configurar um conjunto de dados específico para conter cada uma das árvores do sistema de arquivos que deseja gerenciar dessa forma. 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 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 esta referência a alguém que usa clones de forma eficaz:http://thegreyblog.blogspot.com/2009/05/sparing-disk-space-with-zfs-clones.html

Não estou muito familiarizado com o btrfs, mas se ele suportar as opções que você deseja, você já pensou em configurar um servidor separado apenas para oferecer suporte a esses conjuntos de dados, usando Linux e 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 filho do conjunto de dados clonado. Ainda não usará blocos extras. Editar:Observou que isso apenas reverte o relacionamento pai/filho, não o destrói.

No que diz respeito às coisas sendo compactadas/criptografadas e tornando a cópia mais lenta, isso é completamente falso. Seu processador é muito mais rápido do que seu dispositivo de bloco (mesmo 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 à CPU. A CPU começa a descompactar e descriptografar enquanto o disco começa a ler o bloco 2. A CPU terminará sua tarefa em 3 segundos e então passará os próximos 7 segundos aguardando no disco. Enquanto isso, o disco gastou exatamente a mesma quantidade de tempo lendo esses dois blocos (20 segundos), independentemente de os blocos estarem compactados ou não.

Da mesma forma, durante a escrita, apenas o primeiro bloco é atrasado. A CPU compacta/criptografa o bloco 1 e o envia para o disco. Enquanto o disco está gravando o bloco 1, a CPU começará a compactar/criptografar os blocos subsequentes. A CPU irá mastigar os blocos muito mais rápido do que o disco pode gravá-los, então isso não é um problema. (Sim, é mais complexo do que isso, mas esta é a essência.)

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