LTO-7 테이프의 tar 아카이브에서 로컬로 마운트된 네트워크 공유로 파일을 복원하고 있습니다. 공유에 직접 복원하면 실행 속도가 매우 느려집니다(90MB/s). 추가 버퍼를 사용할 때 얻을 수 있는 최대 처리량은 280MB/s입니다. 하지만 파이프가 파손되었다는 경고가 표시됩니다.
mbuffer -s 1M -m 2G -i /dev/st0 | tar -xf -
mbuffer: warning: error during output to <stdout>: Broken pipe
tar 아카이브는 원래 블록 인수 2048(예: 1MB 블록 크기)을 사용하여 작성되었습니다.
나는 이것이 모든 데이터가 수신되기 전에 tar가 종료되었음을 의미한다고 추측합니다(아마도 버퍼가 일시적으로 비어 있었고 tar는 데이터가 끝났다고 생각했을까요?).
이 문제를 어떻게 해결할 수 있나요? 즉, tar가 버퍼로부터 모든 데이터가 수신될 때까지 기다리는 것을 어떻게 보장할 수 있습니까?
애초에 버퍼링이 필요한 이유는 무엇입니까? 연결은 10G이고 대상 디스크는 매우 빠른 RAID입니다. 경기 둔화의 근본 원인은 무엇입니까?
2020년 2월 7일 수정
tar 명령에 차단 요소를 추가했지만 경고가 나타나지 않았습니다.
mbuffer -s 1M -m 2G -i /dev/st0 | tar -x -b 2048 -f -
그런데 지정되지 않은 경우 파이프 손상 경고가 표시되는 이유가 여전히 궁금합니다.
답변1
오류 메시지가 나타나는 이유는 간단합니다. 사용 중인 tar 구현이 호출하기 전에 모든 데이터를 읽지 않습니다 exit().
이는 실제 테이프 블록 크기를 알려주지 않았기 때문에 발생합니다(직접 발견한 대로).
일반적인 테이프(QIC 테이프 제외)는 차단되며 더 높은 성능을 위해서는 더 큰 블록 크기를 사용하는 것이 좋습니다. 126kB보다 큰 블록 크기를 다른 블록과 교환하는 것은 권장되지 않지만 백업의 경우 1MB를 블록 크기로 사용하는 것이 좋습니다.
TAR다른 쪽도 기본 블록 크기가 10kB인 작업 블록 지향으로 지정됩니다.
EOF아카이브의 정의는 TAR마지막 파일 바로 뒤에 있는 2개의 0으로 된 512 블록입니다(여기서 tar새 헤더가 필요합니다).
EOF 표시 후 아카이브 처리가 중지되고 테이프 데이터의 마지막 10kB에서 0으로 지정된 두 개의 블록이 발생하지 않는 한 읽지 않은 입력이 있으므로 손상된 파이프 메시지가 표시됩니다.
을 사용하는 경우 starFIFO는 내부 tar이므로,테이프 판독 코드그리고 tar아카이브 처리는 항상 테이프 블록 크기에 대해 동일한 생각을 가지고 있습니다. 더 빠른 것 외에도 star모든 입력 데이터가 tar archive.
참고: 최적의 스트리밍을 위해 권장되는 FIFO 버퍼 크기는 최대 테이프 속도에서 10~30초의 데이터를 유지할 수 있습니다. 더 큰 FIFO를 지원하도록 완전히 향상될 때까지 star다음을 호출하는 것이 좋습니다.
star fs=2000m ...
참고: 이는 30년 이후의 기본값입니다 -fifo. star또한 -shm이 기능에 사용할 수 있는 메모리 양이 제한되어 있으므로 Linux에서는 유사한 옵션을 사용하지 않는 것이 좋습니다.
star확실히 다른 어떤 구현보다 빠릅니다 tar. 그러나 COW유사한 파일 시스템을 사용 중이 ZFS거나 운영 체제의 커널 버퍼링 구현 속도가 느린 경우 추출 모드에서 호출을 비활성화하여 속도를 높이는 것이 좋습니다 fsync(). 파일이 백업 저장소에 안전한지 알 수 있는 방법이 없기 때문에 다른 구현보다 "신뢰할 수 없습니다" . 그러나 -no-fsync이렇게 하면 버퍼링이 좋지 않은 레거시 파일 시스템에서 추출 속도가 4배 향상될 수 있습니다. 그러나 불량 버퍼링은 구현되지 않고 높은 비용으로 특정 파일 시스템 상태를 부여하는 기능만 구현됩니다.startarZFSZFS