☰

Linux CentOS에서 LTO6 테이프 읽기 속도가 매우 느림

tag-icon • tag-icon centos performance dd tape
Linux CentOS에서 LTO6 테이프 읽기 속도가 매우 느림

기술 전문가 여러분,

나는 속도 측면에서 큰 성공을 거두지 못한 채 몇 주 동안 LTO6 테이프에서 데이터를 추출하려고 노력해 왔습니다.

테이프 내용을 큰 바이너리 파일로 덤프하기 위해 "dd"를 사용하고 있습니다. 왜냐하면 테이프가 어떤 형식으로 기록되었는지 모르기 때문입니다(확실히 TAR이 아닙니다). 기본적으로 다음 명령을 사용합니다.

dd if=/dev/nst0 of=tape.dump bs=512k

이 작업을 수행할 때 속도는 항상 약 4.7MB/s입니다. 또한 블록 크기를 조정할 때 이 속도를 초과할 수는 없는 것 같습니다. 항상 최대 4.7MB/s에 도달합니다.

더 많은 통찰력을 얻기 위해 읽기 작업 중에 Tapestat를 실행했지만 내가 볼 수 있었던 유일한 것은 읽기 작업이 완료되기를 100%(및 99%) 기다리고 있다는 것이었습니다.

st0         4       0        3.4M        0.0k   6%   0%   6%       0       0

Tape:     r/s     w/s   kB_read/s   kB_wrtn/s  %Rd  %Wr  %Oa    Rs/s    Ot/s
st0        72       0       36.0M        0.0k  98%   0%  98%       0       0

Tape:     r/s     w/s   kB_read/s   kB_wrtn/s  %Rd  %Wr  %Oa    Rs/s    Ot/s
st0        73       0       36.5M        0.0k 100%   0% 100%       0       0

Tape:     r/s     w/s   kB_read/s   kB_wrtn/s  %Rd  %Wr  %Oa    Rs/s    Ot/s
st0        72       0       36.0M        0.0k  98%   0%  98%       0       0

Tape:     r/s     w/s   kB_read/s   kB_wrtn/s  %Rd  %Wr  %Oa    Rs/s    Ot/s
st0        73       0       36.5M        0.0k 100%   0% 100%       0       0

Tape:     r/s     w/s   kB_read/s   kB_wrtn/s  %Rd  %Wr  %Oa    Rs/s    Ot/s
st0        72       0       36.0M        0.0k  98%   0%  98%       0       0

또한 출력 파일 /dev/null을 사용하여 읽기 작업을 수행할 때 속도가 동일하게 유지되므로 기본 디스크 속도가 "구두 광택" 효과를 일으키는 것으로 나타나지 않습니다.

제가 사용한 하드웨어는 SAS를 통해 CentOS8을 실행하는 HPE DL385G7 서버에 연결된 HPE Ultrium 6 외부 테이프 드라이브였습니다.

연구를 시작할 위치에 대한 도움이나 안내를 주시면 대단히 감사하겠습니다!

감사해요

답변1

글쎄, 나는 마침내 적당한 속도로 테이프를 버릴 수 있었습니다. 현재 제가 사용하고 있는 프로세스는 기본적으로 테이프의 각 부분에 대해 서로 다른 블록 크기를 사용하는 것에 의존합니다. 현재 블록 크기가 64KB인 테이프의 처음 2KB를 읽은 다음 몇 블록(테스트에 400 사용)에 대해 65KB(이상한 것으로 알고 있음)로 전환합니다. 그런 다음 명령이 자동으로 일치할 때까지 64KB로 다시 전환합니다 dd: error reading '/dev/nst0': Cannot allocate memory. 이 시점에서 테이프의 처음 4GB가 읽혀집니다.

테이프의 나머지 부분은 65KB 블록 크기로 다시 전환할 수 있으며 속도는 적당합니다(~100MB/s). 테이프의 데이터를 분석할 때 각 64KB 블록에 1KB의 "패딩"이 있는 것으로 나타나므로 65KB 블록 크기를 사용하는 것은 놀라운 일이 아닐 것입니다.

[root@tapepoc TapeBlobExtractor]# dd if=/dev/nst0 of=/tape_dump/tape_1.dump bs=64k
dd: error reading '/dev/nst0': Cannot allocate memory
0+2 records in
0+2 records out
2048 bytes (2.0 kB, 2.0 KiB) copied, 3.28837 s, 0.6 kB/s
[root@tapepoc TapeBlobExtractor]# dd if=/dev/nst0 of=/tape_dump/tape_2.dump bs=65k count=400
dd: warning: partial read (7168 bytes); suggest iflag=fullblock
11+389 records in
11+389 records out
26167296 bytes (26 MB, 25 MiB) copied, 5.26119 s, 5.0 MB/s
[root@tapepoc TapeBlobExtractor]# dd if=/dev/nst0 of=/tape_dump/tape_3.dump bs=64k
dd: error reading '/dev/nst0': Cannot allocate memory
60413+4 records in
60413+4 records out
3959387136 bytes (4.0 GB, 3.7 GiB) copied, 17.4649 s, 227 MB/s
[root@tapepoc TapeBlobExtractor]# dd if=/dev/nst0 of=/tape_dump/tape_4.dump bs=65k
^C1024568+19746 records in
1024568+19746 records out
68377951232 bytes (68 GB, 64 GiB) copied, 641.83 s, 107 MB/s

답변2

조치를 취하기 전에 몇 가지 진단 테스트를 실행하여 문제를 파악하는 것이 좋습니다.

헤드 마모, 가이드 롤러 문제, 모터 문제 등 드라이브 관련 문제로 인해 테이프 드라이브 속도가 느려집니다. 그 이유는 오류율이 높을 때 드라이브가 읽기 프로세스를 다시 시도하기 때문입니다. 테이프 드라이브는 결함, 가장자리 손상, 표면 잔해 등 미디어 관련 문제로 인해 속도가 느려질 수도 있습니다. 디스크, PCIe, HBA, 케이블 등 시스템 주변의 병목 현상도 원인일 수 있습니다. 따라서 올바른 조치를 취하려면 문제를 격리해야 합니다.

국제 비즈니스 기계 공사ITDT적절한 진단 테스트를 수행할 수 있습니다. 특히 이런 상황에서는 "시스템 테스트"가 유용할 수 있습니다. 시스템 테스트는 간단한 진단 테스트이며 하드웨어 압축 유무에 관계없이 다양한 블록 크기와 전송 속도에 대한 결과를 보여줍니다. 이 테스트에서는 데이터가 지워지므로 새로운 미디어를 사용해야 합니다.

압축되지 않은 전송 속도가 사양(=160MB/초)을 벗어나면 새 테이프를 사용하고 있기 때문에 드라이브 문제가 원인입니다. 또한 압축된 전송 속도는 시스템, 케이블 또는 HBA로 인한 대역폭 제한을 나타냅니다.

이 테스트에는 매우 짧은 길이의 테이프가 포함됩니다. 전체 미디어를 테스트하려는 경우 "모두 쓰기" 테스트라는 또 다른 테스트가 있습니다. 전체 볼륨 쓰기를 수행하는데 몇 시간이 걸립니다. 테스트가 완료되면 쓰기 용량과 전송 속도가 표시됩니다. 각각 2.5TB와 160MB/초를 충족하지 못하는 경우 근본 원인은 드라이브 관련 문제입니다.

관련 정보