Copiar dados com rsync causa discrepâncias de tamanho

Question

Estou trocando de máquinas e conectei o disco rígido antigo ( /dev/sda4 ) à nova máquina.

A máquina antiga tinha um disco rígido um pouco menor ( 720G ), comparado com o novo ( 736G ), então criei uma partição um pouco maior também.

Então, eu executei rsync para copiar todos os dados para a nova partição, conforme mostrado abaixo:

linux-70e2:/ # time rsync -azprvl /mnt/external-disk/foo /media/sda4/

...
sent 169,237,139,987 bytes  received 24,529 bytes  24,419,185.41 bytes/sec
total size is 190,542,953,489  speedup is 1.13

real    115m30.297s
user    112m13.068s
sys     3m59.996s

Os dados são copiados sem erros.

No entanto, quando faço:

du -h -m -s /mnt/external-disk/foo /media/sda4/foo

Eu recebo:

162414  /mnt/external-disk/foo
181721  /media/sda4/foo

Alguém poderia, por favor, explicar essa enorme diferença? Por que não estou obtendo os mesmos resultados? Isso está me deixando louca por dias agora. Existem algumas outras partições também e estou recebendo discrepâncias semelhantes também.

Ambas as partições são ext4 .

linux-70e2:/ # mount | grep sda4
/dev/nvme0n1p5 on /media/sda4 type ext4 (rw,relatime,data=ordered)
/dev/sda4 on /mnt/external-disk type ext4 (rw,nosuid,nodev,relatime,data=ordered,uhelper=udisks2)

No meu conhecimento, não há nada errado com as duas unidades, que são SSD-s. Um deles é novo. Eu corri e2fsck em ambos.

Além disso, eu corri:

find -L /mnt/external-disk type/foo -type l

e isso não lista nenhum link simbólico abaixo do diretório de origem.

Esta não é minha primeira vez usando rsync para esse tipo de coisa, mas eu nunca tive esse tipo de problema antes. Por favor, avise!

    

Answer 1

A discrepância é provavelmente causada pelo arquivo mais esparsamente ocupado no disco antigo.

De qualquer forma, primeiro vamos verificar se o arquivo e os números de inode são os mesmos:

• emite find <path> | wc -l em ambos os pontos de montagem. O número de arquivos / diretórios é o mesmo?
• emite df -i . O número de inodes é o mesmo?

Se a resposta a ambas as perguntas for sim, a diferença pode ser explicada por um arquivo mais escasso no novo disco. Mas o que são arquivos esparsos? Em suma, arquivos esparsos são arquivos normais que são menores do que aparentam. Isso é possível graças a um recurso de sistemas de arquivos (relativamente) modernos que, em vez de escrever todos os zeros em um arquivo, simplesmente definem um sinalizador dizendo ao sistema "esse arquivo (ou parte dele) está cheio de zeros, não me deixe escrever todos eles ".

Por padrão, du informa o espaço real ocupado pelo arquivo e não o tamanho aparente. Para mostrar o tamanho aparente, use du --apparent-size (para outras opções, consulte du manpage )

Para um exemplo prático, você pode criar um arquivo esparso usando o comando truncate test.img -s 1G . Conforme relatado por ls , o arquivo recém-criado tem 1 GB de tamanho, mas se você tentar du -hs test.img , verá um tamanho de arquivo muito pequeno (possivelmente zero!). Como isso é possível? Como dito acima, o moderno sistema de arquivos às vezes "mente" aos aplicativos, relatando um tamanho alocado que não existe na realidade. Do outro lado, du -hs --apparent-size test.img imprimirá o mesmo tamanho que ls .

Quando você começar a escrever em um arquivo esparso, o sistema de arquivos alocará dinamicamente o espaço necessário. Por exemplo, a emissão de dd if=/etc/services of=test.img conv=notrunc,nocreat gravará alguns dados no arquivo test.img anteriormente todo esparso. Agora, a execução de du -hs test.img reportará os ~ 600 KB alocados para armazenamento de dados.

Uma implicação óbvia, mas muito importante, é que o suporte a arquivos esparsos só pode otimizar arquivos com preenchimento zero (ou parte deles). No mesmo momento em que você escreve em um arquivo, seu espaço alocado começa a crescer. Este é um evento verdadeiro se você gravar outros zeros no arquivo, a menos que o aplicativo saiba como lidar com arquivos esparsos (nesse caso, o aplicativo informará ao sistema de arquivos que ele vai gravar todos os zeros e otimizar o sistema de arquivos). / p>

E se você quiser realmente pré-alocar algum espaço? Então você pode usar fallocate test.img -l 1G . Se você executar ls; du -hs test.img; du -hs --apparent-size test.img , verá que todas as ferramentas relatam o mesmo tamanho, porque o arquivo foi realmente totalmente alocado pela chamada fallocate .

Em resumo, é possível que, durante a cópia, alguns arquivos tenham sido recriados de maneira menos esparsa, substituindo seções esparsas por zeros "reais". Para usar o arquivo esparso com rsync você precisou usar a opção -S .

    

Answer 2

Quando eu vi diferenças como esta no passado, era geralmente devido a uma diferença no tamanho do bloco das unidades. Isso é especialmente verdadeiro se a unidade original for mais antiga. Você pode verificar isso com o seguinte.

tune2fs -l /dev/sdXX | grep -i 'block size'

    

Answer 3

Suas opções de rsync não copiam hardlinks, tente adicionar -H

-H, --hard-links This tells rsync to look for hard-linked files in the transfer and link together the corresponding files on the receiving side. Without this option, hard-linked files in the transfer are treated as though they were separate files. When you are updating a non-empty destination, this option only ensures that files that are hard-linked together on the source are hard-linked together on the destination. It does NOT currently endeavor to break already existing hard links on the destination that do not exist between the source files. Note, however, that if one or more extra-linked files have content changes, they will become unlinked when updated (assuming you are not using the --inplace option).

Arquivos esparsos, como imagens de VM, também podem estar inflando o uso, substituindo espaços vazios por blocos reais. Tente usar a opção --sparse com o rsync.

Você também pode tentar usar diff para comparar as árvores de diretórios. Veja link