--checksum 및 --ignore-times 옵션의 비동기 차이

95

누구나 rsync의 옵션 --checksum과 --ignore-times옵션의 차이점을 명확히 할 수 있습니까 ?

나의 이해는 다음과 같습니다.

--checksum
파일 크기와 시간이 일치하면 양쪽 끝에 체크섬을 수행하여 파일이 실제로 같은지 확인합니다.

--ignore-times
파일 시간이 양쪽 끝에 동일한 지 여부에 관계없이 모든 파일을 '전송'합니다. 델타 전송 알고리즘을 계속 사용하기 때문에 파일이 실제로 동일하면 아무것도 전송되지 않습니다.

그것은 기술적 차이이지만, 내가 알 수있는 한, 그것들은 의미 상 동일합니다.

그래서, 내가 궁금한 것은 :

두 옵션의 실제 차이점은 무엇입니까?
어떤 경우에 다른 것보다 하나를 사용 하시겠습니까?
그들 사이에 성능 차이가 있습니까?

rsync

— 앤디 매지
소스

99

일반적으로 rsync소스 및 대상 측에서 파일의 크기와 시간이 동일한 경우 파일을 건너 뜁니다. 이 방법 rsync은 소스와 대상에서 거의 동일한 파일의 내용을 검사 하지 않아도 되기 때문에 일반적으로 좋은 생각 인 휴리스틱입니다 .

--ignore-times알 rsync파일 배 앤 크기의 휴리스틱을 끄고, 따라서 무조건 대상으로 소스에서 모든 파일을 전송할 수 있습니다. rsync그런 다음 델타 전송 알고리즘을 사용하거나 --whole-file옵션이 지정 되었는지 여부에 따라 모든 파일을 전체로 보내야하기 때문에 소스 측의 모든 파일을 계속 읽습니다 .

--checksum또한 파일 시간 및 크기 휴리스틱을 수정하지만 여기서는 시간을 무시하고 크기 만 검사합니다. 크기가 다른 소스 및 대상 측의 파일은 분명히 다르기 때문에 전송됩니다. 크기가 같은 파일은 체크섬 ( rsync버전 3.0.0+의 MD5 또는 이전 버전의 MD4)과 합이 다른 파일도 전송됩니다.

소스와 대상이 대부분 동일한 경우 --checksum대부분의 파일이 양쪽에서 체크섬됩니다. 시간이 오래 걸릴 수 있지만, 특히 델타 전송 알고리즘을 사용하는 경우 가장 작은 최소 데이터가 실제로 전송됩니다. 물론, 네트워크 속도가 매우 느리거나 CPU 속도가 매우 빠른 경우에만 승리입니다.

--ignore-times반면에, 네트워크를 통해 더 많은 데이터를 보내면 모든 소스 파일을 읽게되지만 최소한 소스 및 대상 CPU에서 많은 암호로 강력한 해시 섬을 계산해야하는 추가적인 부담은 없습니다. 이 옵션이 --checksum네트워크 속도가 빠르거나 CPU 속도가 상대적으로 느릴 때보 다 성능이 좋을 것으로 기대합니다 .

나는 오직 사용하는 것이 생각 --checksum이나 --ignore-times내가 누구의 수정 시간 변경되지 하였다가 일부 파일의 내용이 손상되었다고 의심 목적지 만에 파일을 전송 한 경우. 다른 유스 케이스가 있지만 옵션을 사용해야하는 다른 좋은 이유는 실제로 생각할 수 없습니다.

— 스티븐 월요일
소스

12

백업 확인 --checksum과 함께 유용하다는 것을 알았습니다 --itemize-changes. 현재 매일 / 매주 업데이트가 완료된 후마다 내 백업 스크립트가이 방식으로 전체 비교를 실행합니다. --itemize-changes예상치 못한 결과가 출력 되면 긴급으로 표시된 이메일을 삭제 했으므로 조사해야 할 잠재적 인 문제가 있음을 알고 있습니다.

— David Spillett

10

--checksum은 Git에서 작업하고 파일이 변경된 분기 간을 전환 할 때 유용하며, 특정 분기에서 보내지 않으려는 파일의 업데이트 시간을 계속 변경합니다.

— FriendlyDev

6

--ignore-times--checksum기본적으로 파일의 타임 스탬프가 업데이트되지 않기 때문에 "파일"중 하나가 Truecrypt 파일 컨테이너 인 경우 특히 필요합니다. 참조 productforums.google.com/forum/#!topic/drive/gnmDp3UXEgs 및 ask-leo.com/why_wont_my_truecrypt_volume_backup.html

— 마르쿠스 유니 우스 브루투스

참고 : 나는 빠른 실험을했고 ctime은 비교되지 않고 mtime 만 비교됩니다. Mac에서는 최소한. 알고 있으면 유용 할 수 있습니다. 이것이 Windows 파일 시스템에 너무 많은 문제가있는 이유인데, atime, mtime 및 ctime에 대해 동일한 시간 (ctime)을보고합니다.

— Edward Falk 2012 년

--checksum대상 시스템의 소스 파일 이름 또는 대상 디렉토리의 모든 파일 만 체크섬 합니까 ?

— 그렉

16

체크섬은 다른 시스템을 사용하여 파일을 동기화하고 타임 스탬프를 보존하지 않은 경우에도 유용합니다. 체크섬은 다른 파일 만 전송하고 수신 측의 모든 타임 스탬프를 업데이트하여 일치하도록

— 파울루스
소스

4

한 가지 세부 사항 : 체크섬 옵션은 한쪽 끝에서 전체 파일을 확인한 다음 다른 쪽 끝에서 전체 파일을 확인합니다. 파일이 다소 크면 이런 종류의 병렬 처리가 중단됩니다.

또한 대용량 파일이있는 경우을 사용 --checksum하지 않고을 사용하여 시간 초과가 발생할 가능성이 큽니다 -I.

— 프랑소와
소스

2

에서 info rsync받는 관해서 --checksum옵션 - "연결의 양쪽에있는 모든 파일의 전체 파일 체크섬 파일의 전송 과정에서 발생하는 자동 체크섬 검증에 추가로 발생하기 때문에,이 옵션은 매우 느릴 수 있습니다."

— LeoB
소스

1

그 문장이 내 맨 페이지에없는 것 같습니다 ... 그래서 체크섬 옵션은 체크섬을 사용하여 파일이 동일한 지 여부를 식별하고 파일이 일치하지 않으면 파일을 전송하여 체크섬을 다시 생성한다는 것을 의미합니다 양도의 일부? --ignore-times 옵션은 검사를 건너 뛰고 변경했다고 가정합니까? 따라서 성능 측면에서 무시하는 것이 같은 일을 달성하는 더 좋은 방법입니까? 나는 아직도 (떨어져 --checksum 더 투명 사실에서) 2 개 가지 옵션이 있습니다 이유를 사투를 벌인거야

— 앤디 매지

당신은 최신 문서 편집 봐야한다 : gitweb.samba.org/...

— 알렉산드르 Levchuk

2

이 --ignore-times옵션을 사용하면 모든 파일이 델타로 인코딩되고 델타 전송 알고리즘 (델타 인코딩)이 적어도 체크섬만큼 느립니다.

--ignore-times델타 전송이 전송되지 않는 경우가 빈번한 경우 "자동 전송 후 확인"을 피하기 위해 rsync 가 충분히 똑똑한 지 잘 모르겠습니다 .

의 경우 --ignore-times:

rsync가 똑똑하지 않은 경우 (또는 델타 인코딩을 신뢰하지 않는 경우) 확인 (체크섬 및 인코딩)이 두 번 수행됩니다.
델타 인코딩이 128 비트 MD4 체크섬보다 훨씬 느릴 수도 있습니다.

모두 --checksum와는 --ignore-times"상당히 느린"이 될 것이지만 --ignore-times(때문에 둘 가능성 위에서)도 느린 것 같다.

좋은 질문-실제로 성능 차이가 있으면 게시하십시오.

— 알렉산드르 레프 추크
소스

무슨 말인지 알 겠어 몇 가지 테스트를 실행하고 다시 게시하겠습니다.

— Andy Madge