LAN에 데비안 머신이 있는데 다른 서버의 백업 서버 역할을합니다. 4 개의 HDD가 소프트웨어 RAID 5 md 장치, LVM 및 btrfs에 결합되어 있습니다. 백업은 rsync를 사용하여 이루어지며 큰 파일 시스템의 경우 한 시간 이상이 걸립니다. 오랫동안 나는 이것에 대해 할 수있는 일이 거의 없을 것이라고 생각했습니다.
그러나 최근 에는 전송의 양쪽 끝 에서 HDD 활동이 매우 다르다는 것을 알았습니다 . 젠투를 실행하고 주로 ext4를 사용하는 송신 측은 디스크 입출력을 거의 얻지 못했지만 수신 측은 끊임없이 바빴습니다. 대부분의 데이터는 전송간에 변경되지 않으므로 메타 데이터 읽기는 대부분의 데이터를 구성해야한다고 생각합니다. 그러나 btrfs에서 inode를 읽는 것이 ext4에서 동일한 작업을 수행하는 것보다 많은 일이라면 정말 놀랐습니다.
iotop 수신 측에서는 디스크 읽기가 약 1-4MB / s 인 반면 송신 측은 가끔 0.5MB / s 버스트 만 발생했습니다.
내 질문은, 여기에 무슨 일이 일어나고 있는지 설명 할 수 있습니까? 가능하면 문제를 해결하는 방법을 알려주는 것이 좋습니다.
아마도 내가 사용할 수있는 btrfs 튜닝 플래그 또는 이와 유사한 것이있을 수 있습니다. 백업 서버에 스냅 샷 기능이있는 FS가 필요하며 FreeBSD와 ZFS를 사용하려는 시도가 FS와 일치하지 않아서 btrfs에 대한 대안이 거의 없습니다. 따라서 ext4 또는 zfs를 사용하라는 응답은 공표를받을 수 있지만 확인 표시는받지 않습니다.
cjm 에서 요청한대로 사용중인 Rsync 옵션 :
--rsync-path='rsync --fake-super'
--archive # -rlptgoD
--hard-links # detect and preserve these
--acls
--xattrs
--sparse
--noatime # based on patch from samba #7249c1
--delete
--delete-delay
--fuzzy
--human-readable # size suffixes, base 1000
--stats
뿐만 아니라 한 무리의 -f규칙 일부 파일을 생략합니다.
btrfs의 마운트 옵션은 다음 mount과 같이 보고됩니다 .
rw,nosuid,noexec,noatime,nospace_cache
특히, 여기에는 noatime플래그가 포함 되므로 실제로 일부 파일에 차이가없는 한 어떤 글도 포함되어서는 안됩니다. Kyle Jones 의 답변 에 따라이 정보를 추가했습니다 .
dtrace또는 systemtap시간이 소요되는 곳을 찾을 수 있습니다.