Recentemente a notícia foi divulgada que o criador do kernel Linux, "Linus Torvalds" aceito no ramo principal (com base na versão 5.4 é formada) a implementação do módulo dm-clone com a implementação de um novo controlador com base no mapeador de dispositivos.
Esta nova proposta para kernel Linux permitirá que você clone um dispositivo de bloco existente. O módulo permite criar uma cópia local baseada em um dispositivo de bloco somente leitura que pode ser gravado durante o processo de clonagem.
Como uma aplicação típica do módulo proposto para o kernel Linux "Dm-clone" refere-se à clonagem de rede de dispositivos de arquivos remotos em modo somente leitura e processamento de E / S com longos atrasos, para um dispositivo local rápido que suporta a gravação e processamento de solicitações com atrasos mínimos.
Com isso oferece a capacidade de montar o dispositivo clonado e começar a usá-lo imediatamente após sua criação, sem esperar que o processo de transferência de dados termine.
Por outro lado, a cópia de informações continuará em segundo plano, em paralelo com a entrada / saída gerada ao acessar um novo dispositivo.
O principal caso de uso do dm-clone é clonar uma latência potencialmente remota, dispositivo de bloqueio do tipo de arquivo somente leitura em um dispositivo do tipo primário gravável.
Por exemplo dm-clone pode ser usado para restaurar backups de armazenamento anexados à rede disponível por meio de protocolos como NBD, Fibre Channel, iSCSI e AoE no armazenamento local baseado em SSD ou NVMe.
O código dm-clone é otimizado para pequenas gravações aleatórias cujo tamanho corresponde ao tamanho do bloco (4 K por padrão).
Durante o processo de clonagem, as solicitações de leitura levarão a uma solicitação direta de dados do dispositivo clonado e as solicitações de gravação que afetam as áreas que ainda não foram sincronizadas serão atrasadas até que o carregamento não programado dos blocos solicitados seja concluído (o as operações de carregamento para os blocos relacionados à gravação começam instantaneamente).
Blocos removidos pela operação "discard" são excluídos do processo de cópia (após a montagem, o usuário pode executar "fstrim / mnt / cloned-fs" para evitar a cópia de blocos que não são usados no FS).
A informação sobre mudanças e dados em blocos carregados eles são armazenados em uma tabela de metadados local separada.
Após a conclusão da clonagem, o usuário recebe uma cópia de trabalho completa do dispositivo de origem, refletindo todas as alterações feitas desde o início da clonagem.
Uma tabela com metadados clones pode ser eliminada após a sincronização, substituindo-a por uma tabela de linhas que reflete diretamente os dados para um novo dispositivo.
A principal diferença das soluções baseadas em Unionfs e OverlayFS é que o dm-clone funciona no nível do dispositivo de bloco, independentemente do sistema de arquivos usado neste dispositivo, e forma uma cópia completa do dispositivo de origem e não impõe uma camada adicional. onde as mudanças são rastreadas.
Ao contrário do dm-mirror, o módulo dm-clone foi originalmente projetado para funcionar apenas com a seção original no modo somente leitura, sem traduzir as operações de gravação para ela.
No dm-snapshot, uma cópia completa não é criada e a cópia em segundo plano não é suportada. No dm-cache, uma cópia completa não é criada, as operações de gravação são encaminhadas e o trabalho é reduzido a ocorrências de armazenamento em cache. A funcionalidade mais próxima é dm-thin.
dm-clone usa dm-kcopyd para copiar partes do dispositivo de origem para o dispositivo de destino. Por padrão, são emitidos pedidos de cópia de um tamanho igual ao tamanho da região.
Uma mensagem `hydration_batch_size <#regions>` pode ser usada para ajustar o tamanho dessas solicitações de cópia. Aumentar o tamanho do lote de hidratação resulta no clone dm tentando agrupar regiões contíguas, então copiamos os dados em lote dessas muitas regiões.
fonte: https://git.kernel.org