Use btrfstune -u para alterar o UUID após dd e antes da montagem.
Como pode fazer uma cópia completa do conteúdo de um sistema de arquivos btrfs? Por cópia completa , quero dizer não apenas os dados atuais , mas também subvolumes com seus instantâneos , idealmente preservando suas Estruturas CoW (ou seja, não duplicar blocos com o mesmo conteúdo.
Parece que uma cópia em nível de bloco (como em dd ) não é uma boa idéia, já que ela duplica o UUID e não há como alterá-lo facilmente , aparentemente.
Eu não encontrei nenhuma solução pronta a partir de hoje (2016-05-06), mas resolvi o problema para os meus propósitos, incluindo a manipulação da Cópia na gravação. As etapas para "clonar" /source to /target são:
Obtenha uma lista de subvolumes ordenados por ogen : btrfs subvolume list -qu --sort ogen /source . A classificação provavelmente é suficiente para garantir que os instantâneos ou subvolumes que dependem dos anteriores sejam tratados primeiro. Isso é importante para lidar com a cópia na gravação, porque precisamos ter os volumes base transferidos primeiro.
Torna todos os subvolumes somente leitura usando btrfs property set -ts /source/some-volume ro true .
Agora, para cada subvolume da lista acima, começando pela parte superior, faça o seguinte:
Se o volume não tiver um UUID pai (exibido como - ) ou o UUID pai não existir mais na lista, execute: btrfs send /source/some/volume | btrfs receive /target/some/
Se o volume tiver um UUID pai que ainda existe, já deveríamos tê-lo transferido por causa de --sort ogen e podemos usá-lo como base para evitar a duplicação de dados. Portanto, localize o caminho do UUID pai na lista e execute: btrfs send -p /source/parent/volume/ -c /source/parent/volume/ /source/some/volume/ | btrfs receive /target/some/ (o btrfs provavelmente adivinharia o argumento -p automaticamente, mas prefiro ser explícito).
Depois de executar um dos comandos acima, torne o destino e a fonte de leitura / gravação novamente: btrfs property set -ts /source/some/volume ro false; btrfs property set -ts /target/some/volume ro false . Esta etapa pode ser ignorada se a fonte tiver sido previamente somente leitura.
Isso deve lidar com muitos casos. Advertências:
Pode haver algumas complicações com relação ao pedido ao aninhar subvolumes / snapshots.
Todo o processo é obviamente mais divertido quando o script é executado.
btrfs send aceita vários argumentos de origem clone ( -c ). Pode ser vantajoso não apenas especificar o caminho de volume do pai, mas também os de qualquer ancestral ou simplesmente qualquer volume enviado anteriormente. Não fez nenhuma diferença aqui, mas pode - apenas um palpite - ajudar a evitar a duplicação de dados em alguns casos.
Não tenho certeza se alguma meta-informação sobre snapshots ou subvolumes é perdida, mas praticamente tudo o mais interessante para a maioria dos casos de uso deve ser preservado.
Todo o processo me ajudou a transferir um sistema de arquivos de 800 GB com 3,8 GB usados (de acordo com df ) para uma imagem de 10 GB com 3,8 GB usados. A transferência sem -p e -c teria usado cerca de 190 GB, portanto a duplicação de dados foi de fato evitada.
Existe uma pergunta semelhante em unix.stackexchange.com que aponta para partclone.btrfs, mas eu não conheço nenhum detalhe específico sobre isso.
Existe também uma discussão na lista de discussão do kernel , não parece realmente promissor ...
Com btrfs-send , que eu vi pela última vez, ainda havia patches experimentais circulando na lista de discussão do btrfs.
Eu criei uma ferramenta python que pode fazer isso. Fiz isso porque tentei a abordagem do @Thomas Luzat tanto na implementação do meu quanto do @Johannes Ernst, e o espaço usado dobrou de 20 GB para 40 GB no procedimento de clonagem. Eu pensei que algo mais eficiente fosse necessário.
Considere este histórico de sistema de arquivos comum:
current ---------------------------------\
| | | |
snap4 snap3 snap2 snap1
Com o algoritmo de Thomas, "atual" seria clonado primeiro, e todos os instantâneos (sendo instantâneos dos antigos estados de "atual") usariam "atual" como origem / pai do clone. Obviamente, seria melhor basear o snap3 no snap4, o snap2 no snap3, etc.
E esta é apenas a ponta do iceberg; Encontrar as "melhores" fontes de clonagem (em termos de economia de espaço) em um sistema de arquivos btrfs com um histórico complexo é um problema não trivial. Eu criei outras três estratégias para resolver esse problema, que parecem usar o espaço de maneira muito mais eficiente. Um realmente resultou no tamanho dos clones ligeiramente abaixo do da fonte.
Você pode ler os detalhes na página do github se estiver interessado.