☰

tar보다 빠른(압축되지 않은) 보관 도구?

tag-icon • tag-icon backup tar archive large-files tape
tar보다 빠른(압축되지 않은) 보관 도구?

저는 LTO-7 테이프에 여러 파일을 보관하기 위해 tar를 사용하고 있습니다. 일반적으로 파일당 약 1-2GB이며 각 아카이브에는 수백 개의 파일이 있을 수 있습니다(아카이브당 최대 약 1TB).

현재 다음을 사용하여 보관하고 있습니다.

tar -cvf /dev/nst0 --totals --warning=no-file-changed $OLDEST_DIR

디스크 전송 속도는 약 90MBps이고, 디스크 전송 속도는 그 속도의 3배입니다(테이프 전송 속도는 그 속도의 2-3배여야 합니다). 자세히 살펴보면 tar가 하나의 CPU를 100% 소비하므로 CPU 바인딩된 것으로 보입니다.

이 작업을 먼저 수행하여 아카이브의 크기가 올바른지 확인하려고 하기 때문에 특히 짜증납니다.

tar -cP --warning=no-file-changed $OLDEST_DIR | wc -c

...그런 다음 결과 아카이브의 크기를 비교합니다.

그렇다면 더 빠른 방법은 없을까요?

답변1

x86-64 CPU의 데이터 처리량은 약 64GB/s이므로 이것이 귀하의 문제는 아니라고 생각합니다. 이것은 x86-64 Linux입니까, 아니면 다른 것입니까? 가장 가능성이 높은 문제는 각 트랜잭션이 CPU 작업을 수행하고 있는데 사용하는 청크가 너무 작다는 것입니다. 노력하다:

strace -fo /tmp/tar.rw.txt -eread,write tar -cvf /dev/nst0 --totals --warning=no-file-changed $OLDEST_DIR

tar가 I/O 차단으로 수행하려는 작업을 보려면 결과 /tmp/tar.rw.txt 파일을 살펴보십시오. 아마도 10KB 블록을 읽고 쓰는 것을 알 수 있을 것입니다. -b기본값은 20인 이 플래그를 사용하여 이 문제를 해결할 수 있습니다 . 귀하의 하드웨어는 메가바이트의 I/O를 처리할 수 있을 것이며, OS가 이를 처리할 수 없으면 다시 분할할 것이므로 -b $[1024*2*32]32MB 트랜잭션을 시도해 보십시오.

다음으로, 운영 체제가 트랜잭션을 통해 무엇을 하려는지 확인해야 합니다. 새로운 값으로 tar를 시도하고 -b, 설치되었는지 확인 하고, sysstat실행하는 동안 iostat -xm 4카운터를 확인하고 관찰하세요 . 주의해야 할 주요 사항은 "avgrq-sz" 열입니다. 분할하지 않으면 약 64,000이 되어야 합니다. 분할이 발생하면 운영 체제는 한 트랜잭션에서 많은 바이트를 읽거나 쓸 수 없다고 생각합니다. 이것은 그 자체로 주제이지만 드라이브에 레이블을 지정하여 제한을 빠르게 늘릴 수 있습니다(nst0이 거기에 있어야 한다고 생각합니다).

cd /sys/block/nst0/queue
cat max_hw_sectors_kb > max_sectors_kb`

읽고 있는 디스크의 모든 레이어(lvm 및 dm 레이어 포함)와 동일합니다. 그것은비판적인가장 낮은(sda) 레벨에서 먼저 max_sectors_kb를 늘리고 가장 높은(예: dm23) 레벨에서 마지막으로 늘립니다. 재귀적으로 확인하세요 /sys/block/<dm>/holders/*/holders/*/.....

이제 이러한 새로운 설정에서는 두 가지에 주의를 기울여야 합니다. 하나는 원본 파일을 md5sum하고 테이프에서 tar 및 untar를 수행한 다음 md5sum을 확인하여 파일이 여전히 올바르게 기록되는지 확인하는 것입니다. -b이와 같은 문제가 발생해서는 안 되지만 테이프 하드웨어 등은 테스트하지 않았습니다. 두 번째는 더 큰 트랜잭션 크기로 인해 RAM이 부족해지지 않도록 하는 것입니다. 디스크 트랜잭션 중에 sysctl vm.min_free_kbytes가 부족해지면 매우 나쁜 일이 발생할 수 있으므로 sysctl vm.min_free_kbytes가 충분히 큰지 확인하고 싶을 수도 있습니다.

관련 정보