![rsync는 모든 종류의 체크섬을 동기화합니까? [복사]](https://linux55.com/image/70774/rsync%EB%8A%94%20%EB%AA%A8%EB%93%A0%20%EC%A2%85%EB%A5%98%EC%9D%98%20%EC%B2%B4%ED%81%AC%EC%84%AC%EC%9D%84%20%EB%8F%99%EA%B8%B0%ED%99%94%ED%95%A9%EB%8B%88%EA%B9%8C%3F%20%5B%EB%B3%B5%EC%82%AC%5D.png)
SSH를 통한 Rsync를 사용하여 여러 서버에서 단일 원격 호스트로 파일을 전송해야 합니다. 그러나 --remove-from-source 매개변수를 사용하여 소스에서 파일을 제거하기 전에 전송된 파일이 실제로 존재하는지 확인해야 합니다.
내가 읽은 바에 따르면 전송 후 체크섬은 없으며 rsync는 커널 응답을 신뢰하지만 해당 기사의 날짜는 2005-2009년입니다. 최근 rsync 업데이트에서 이것이 변경되었는지 궁금합니다. 그렇지 않은 경우 이를 확인하고 확인 후 소스파일을 삭제할 수 있는 방법이 있나요?
편집: 이것이 어떻게 중복되는지 이해가 되지 않습니다. 내 문제는 동일한 시스템의 로컬 드라이브와 관련이 없습니다 ...
답변1
일반화하다: rsync가 디스크에 데이터를 쓰는 경우 손실 없이 수행됩니다. 그러나 완전히 확신하려면데이터는 실제로 디스크에 기록됩니다.fsync.diff, 패치를 적용 하거나 sync <files>나중에 전화해야 합니다.
SSH공급데이터 무결성—수신한 데이터는 보낸 데이터와 동일합니다. 그렇기 때문에 네트워킹을 하는 것입니다.
그런 다음 rsync는 write시스템 호출을 사용하여 커널에 데이터를 디스크에 쓰도록 요청합니다. 이는 또한 하드 드라이브에 오류가 발생하지 않는 한(또 다른 문제) 데이터 무결성을 유지합니다.
하지만,이제 데이터가 실제로 디스크에 있는지 확인하세요.짜증나게도 그렇게 간단하지 않습니다. 이것write매뉴얼 페이지다음 설명을 해보세요:
write()의 성공적인 반환은 데이터가 디스크에 커밋되었음을 보장하지 않습니다. 실제로 일부 버그가 있는 구현에서는 데이터 공간을 성공적으로 예약했다는 보장조차 없습니다. 유일한 확실한 방법은 모든 데이터가 기록된 후 fsync(2)를 호출하는 것입니다.
나다운로드최신(3.1.2pre1) rsync 소스 코드인 grepped에서는 fsync결과가 나오지 않았습니다.기본적으로 rsync는 호출하지 않습니다.fsync(메타데이터가 없는 버전도 찾았습니다 fdatasync. 없음). 즉, write이러한 작업이 완료되었는지 여부는 파일 시스템에 따라 다릅니다.
해결책으로 다음을 수행할 수 있습니다.
Run 은 주어진 파일을
sync <files>호출합니다 .fsync다시 돌아올 때 그들은 확실히 디스크에 있을 것입니다.rsync 소스 패치 디렉터리를 다운로드합니다(별도의 다운로드로 제공됨).
fsync.diffSami Farin의 패치를 적용합니다 . "우리가 작성하는 모든 파일에서 fsync()를 호출하려면 --fsync를 지정할 수 있습니다." (이것이 앞으로는 기본값이 되기를 바랍니다.)
보통 그래도, 최신 파일 시스템은 IO 로드가 높을 때 캐시 자유를 잠시만 사용하여 쓰기를 매우 빠르게 완료합니다. 시스템을 알고 있다면 이 단계를 건너뛸 수 있습니다. 그러나 더 폭넓게 사용하기 위한 코드를 작성할 때 결과는 파일 시스템, 조정 방법, 드라이브의 펌웨어에 대한 신의 자비 여부에 따라 달라질 수 있다는 점을 명심하십시오.