실행 중인 XBian 서버가 있습니다(Raspberry Pi 버전의 Debian).동기화inetd를 통해(기본 데몬 아님) 나는 여러 디렉토리를 제공하고 있습니다외부 4별도의 모듈로 파일 시스템(USB 디스크)(해당 모듈에는 약 100-500GB의 데이터와 1000-10000개의 파일이 있음) 최근에 파일 시스템의 다른 부분(예: 업로드, 복사 등, 반드시 위 디렉터리가 아닐 수도 있음)을 변경할 때 이러한 모듈에 대한 rsync 호출이 시간 초과된다는 사실을 발견했습니다.
파일 전송이 필요하지 않을 것으로 예상되는 이와 같은 루틴 rsync 명령의 경우 rsync -vrt rsync://host:port/module ./
(즉, 서버와 클라이언트 위치 모두 동일한 데이터를 가짐) rsync 서버 로그 파일에 다음과 같은 로그가 표시됩니다.
2014/12/15 22:59:59 [###] connect from UNKNOWN (1.1.1.1)
2014/12/15 22:59:59 [###] rsync on share/ from UNKNOWN (1.1.1.1)
2014/12/15 22:59:59 [###] building file list
2014/12/15 23:16:23 [###] rsync: read error: Connection timed out (110)
2014/12/15 23:16:23 [###] rsync error: error in socket IO (code 10) at io.c(785) [sender=3.1.1]
클라이언트 로그에 다음과 같은 로그가 표시됩니다(예, 동일한 전송 - 서버는 15분 후에 시간 초과를 보고하고 클라이언트는 30분 후에 오류를 보고합니다).
2014/12/15 23:00:01 [###] receiving file list
2014/12/15 23:29:26 [###] rsync: read error: Connection reset by peer (104)
2014/12/15 23:29:26 [###] rsync error: error in rsync protocol data stream (code 12) at /usr/src/ports/rsync/rsync-3.0.9-1/src/rsync-3.0.9/io.c(764) [Receiver=3.0.9]
많은 문제로 인해 이와 같은 상황이 발생할 수 있지만, 다른 문제가 발견된 몇 가지 파일의 조각 모음을 수행한 후 rsync 전송이 다시 성공적으로 완료되기 시작한다는 사실도 확인했습니다. 그런 다음 더 많은 파일을 다시 rsync 모듈 외부 디렉터리에 업로드한 후 시간 초과 반환이 표시됩니다. 이제 시간 초과 오류가 있는 로그를 볼 때마다 조각 모음을 수행합니다(다음을 사용).e4 조각 모음) 그러면 내 시스템이 rsync 전송을 다시 성공적으로 실행할 수 있습니다.
몇 가지 추가 참고 사항:
- 내 ext4 파티션이 현재 여유 공간의 50% 미만을 사용하고 있습니다.
- 다른 소규모 모듈에 대한 rsync 호출이 시간 초과되지 않습니다.
- 데이터 전송이 없는 통화(예:
rsync -rt rsync://host:post/module
)도 이 상태에서는 시간 초과됩니다. - 추가 테스트 후 조각 모음 후에 작동하는 것 같습니다.동기화조각 모음을 다시 수행해야 하기 전에 한 번 성공적으로 호출되었습니다.동기화호출로 인해 실제로 파일 조각화가 발생합니까? )
rsync 설정을 매번 조각 모음해야 하는 이유는 무엇이며, 그러한 사소한 불편으로 인해 rsync가 중단되지 않도록 하려면 어떻게 해야 합니까?
답변1
tar
대신 /dev/null 디렉토리의 조각 모음을 시도해 보십시오 . 이렇게 하면 디스크가 수정되지는 않지만 모든 inode가 캐시됩니다. 많은 파일을 포함하는 대규모 디렉토리의 경우 ext4는 해당 파일을 해시 트리에 색인화하므로 readdir()은 기본적으로 무작위 순서로 파일을 반환합니다. 동일한 순서로 stat()을 시도하면 많은 조회가 발생하여 속도가 매우 느려집니다.
답변2
나는 ext3 및 ext4의 로깅 시스템과 ext4에 대한 Wikipedia 장에 대한 정보를 수집해 왔습니다.할당 지연 및 잠재적인 데이터 손실rsync
, 이것이 조각화의 잠재적 원인이라고 생각하게 만듭니다 . 그 frez가 나를 여기로 데려왔으며 실제로 내가 요청한 프로세스를 설명하는 결과를 보았습니다! tar
to님의 제안이 /dev/null
좋은 해결책인 것 같습니다. 지연 할당에 대해 자세히 알아보려면 링크를 읽어보세요.