Arquivos esparsos significativamente maiores (mas ainda escassos) após a cópia em uma rede

Question

Ao tentar copiar arquivos esparso de imagem da VM de um hypervisor KVM para outro na rede, vejo o seguinte comportamento:

• Os arquivos esparsos ainda são arquivos esparsos
• Os arquivos esparsos copiados são significativamente maiores que os arquivos esparsos originais

Fonte:

[root@kvm1 thin_images]# ls -lhs
total 2.6G
1.4G -rw-------. 1 root root 8.0G Jul 20 11:10 centos6-8g.img
1.3G -rw-------. 1 root root 8.0G Jul 20 10:50 debian7-8g.img

Destino:

[root@kvm2 thin_images]# ls -lhs
total 11G
4.8G -rw-------. 1 root root 8.0G Jul 20 11:10 centos6-8g.img
6.2G -rw-------. 1 root root 8.0G Jul 20 10:50 debian7-8g.img

Como você pode ver, o arquivo esparso para uma imagem do CentOS agora é de 4.8G em vez de 1.4G. Para a imagem Debian, ela cresceu de 1.3G para 6.2G.

Os métodos que eu tentei copiar na rede incluem um tubo sujo de nc-tar e rsync com as opções --sparse e --inplace . Os hypervisors não estão em kernels Linux novos o suficiente para usar a a funcionalidade SEEK_HOLE do bsdtar , nem possuem o próprio bsdtar.

Alguma explicação para esse comportamento? É possível que os arquivos esparsos de destino permaneçam do mesmo tamanho que os arquivos esparsos originais depois de copiá-los em uma rede?

Outras informações:

[root@kvm1 thin_images]# uname -a
Linux kvm1 2.6.32-504.23.4.el6.x86_64 #1 SMP Tue Jun 9 20:57:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
[root@kvm1 thin_images]# yum list installed rsync tar nc
Loaded plugins: fastestmirror, security
Loading mirror speeds from cached hostfile
 * base: centos-mirror.jchost.net
 * extras: mirror.spro.net
 * updates: mirror.es.its.nyu.edu
Installed Packages
nc.x86_64                                                  1.84-22.el6                                                 @base                                   
rsync.x86_64                                               3.0.6-12.el6                                                @anaconda-CentOS-201410241409.x86_64/6.6
tar.x86_64                                                 2:1.23-11.el6                                               @anaconda-CentOS-201410241409.x86_64/6.6

    

Answer 1

rsync etc. normalmente só é disperso após um número definido de bytes e, normalmente, apenas em tamanhos de bloco (precisa ler o código-fonte, mas me lembro de algo sobre ele com tamanhos de bloco) para decidir sobre como usar o escasso métodos. Assim, um bloco com um único byte escrito nele seria copiado e escrito e, portanto, o tamanho do bloco alocado, em vez de apenas uma busca para esse byte, e uma busca para o resto. No (s) arquivo (s) original (es), seriam tamanhos de bloco de 512 bytes, mas as transferências / etc. (para otimização) seria em tamanhos de bloco de 64k. então um único byte definido em um 64kb obtém um 64kb escrito em disco, ao invés de procurar esparsificar esse "bloco".

Você pode ver resultados semelhantes fazendo rsync mesmo no sistema de arquivos local dessas imagens.

Dê uma olhada neles para postar transferências: link e link O conselho nesse link que você deu também se aplicaria:

1. rsync --sparse local dest: // diretório /
2. use essas ferramentas para torná-lo esparso novamente
3. use o rsync --inplace em todas as execuções subseqüentes
4. arquivos esparsos se eles ficarem "grandes demais" novamente