rsync를 사용하여 원본 컴퓨터 C1에서 대상 컴퓨터 D1(동일한 LAN에 있지 않음)로 파일을 전송하고 있습니다. C1(소스)의 파일 A는 D1(대상)의 파일 B의 업데이트된 버전입니다. 파일 A는 850MB이고 파일 B는 530MB입니다.
사용된 명령:
rsync -e "ssh -p 2222 -o StrictHostKeyChecking=no -o ConnectTimeout=10" -avvvz --stats --progress fileA.tar username@destIP:fileB.tar
얻은 통계는 다음과 같습니다.
hash search b=25600 len=899737600
Number of files: 1
Number of files transferred: 1
Total file size: 899737600 bytes
Total transferred file size: 899737600 bytes
Literal data: 709324800 bytes
Matched data: 190412800 bytes
File list size: 38
File list generation time: 0.001 seconds
File list transfer time: 0.000 seconds
Total bytes sent: 617865859
Total bytes received: 153142
sent 617865859 bytes received 153142 bytes 3501524.08 bytes/sec
total size is 899737600 speedup is 1.46
data sent - 617865859 bytes (590mb approx)
rsync의 델타 알고리즘에 따르면 전송된 모든 데이터를 함께 결합하기 위한 체크섬 및 지침을 위한 추가 바이트와 함께 320MB의 차이만 전송되어야 합니다. 하지만 총 590mb가 전송되었습니다. 270MB를 추가로 전송하는 이유는 무엇입니까?
rsync 명령이나 체크섬으로 전달되는 추가 데이터로 인해 이 추가 데이터가 전송됩니까? 아니면 320MB 차이 외에 파일 A에서 추가 데이터가 전송되고 있습니까? 즉, 이 경우 델타 알고리즘이 그다지 효율적이지 않다는 의미입니까?
답변1
업데이트된 아카이브를 전송 중입니다 tar. 대상 위치의 이전 복사본은 약 530Mb이고 업데이트된 파일은 약 850Mb입니다. 차이점크기면에서320Mb인데 전송해야 하는 파일의 처음 530Mb에도 차이가 있다고 가정합니다.
업데이트된 아카이브에 항목만 있는 경우추가의그렇다면 귀하의 우려는 맞습니다. 그러나 아카이브를 다시 생성하는 경우 업데이트된 아카이브의 처음 530Mb에 두 파일을 다른 순서로 추가하거나 아카이브에 추가된 데이터가 실제로 더 긴 크기로 추가됩니다. 작은 파일은 전체에 배포됩니다. rsync변경 사항도 감지 되도록 아카이브합니다 .