알다시피, LTO 테이프는 "랩"으로 데이터를 기록합니다. 첫 번째 랩은 테이프를 드라이브로 스풀링하고 두 번째 랩은이를 카트리지로 스풀링합니다. 이 과정은 여러 번 반복되며, 테이프 끝에 도달하면 모든 테이프가 카트리지에 다시 들어가고 되감기없이 배출 할 수 있다는 아이디어가 있습니다.
그러나 테이프의 끝 부분에 도달하면 드라이브가 최종 포장을 반쯤 마치는 것처럼 들리므로 드라이브는 테이프를 꺼내기 전에 테이프를 되 감는 데 시간이 걸린다는 사실을 알았습니다. 테이프의 끝에 도달했습니다.
테이프에 예약 된 용량이 있기 때문에 실패한 블록을 다시 쓰거나 총 용량을 줄이지 않고 테이프의 불량 섹션을 건너 뛸 수 있습니까? 아니면 테이프의 조기 마감에 대한 다른 이유가 있습니까?
답변:
새 드라이브이고 테이프의 품질이 좋은 경우 공식 용량보다 많은 바이트를 테이프에 쓸 수 있습니다. 어떤 의미에서는 여분의 용량을 호출 할 수 있지만 사용되지는 않습니다.
드라이브 헤드가 마모되면 용량이 줄어 듭니다. 품질이 좋지 않은 테이프와 함께 사용하면 용량이 더 줄어들 수 있습니다.
용량은 용량이 다양하므로 백업 응용 프로그램에 용량이 부족하다는 신호를 보내는 방법이 필요합니다. 테이프 끝에 도달하여 준비되지 않은 경우 백업 응용 프로그램에 문제가 될 수 있습니다. 남은 공간을 사용하여 수행중인 작업을 마무리 할 수 있도록 사전 경고가있는 응용 프로그램에 더 좋습니다.
OS가 Linux 인 경우 API는 테이프의 마지막 부분에 도달 write하면 다른 모든 시스템 호출에 실패 ENOSPC합니다. 백업 응용 프로그램이이 기능에 대해 알지 못하면 첫 번째 기능 ENOSPC은 끝으로 간주 되며 테이프에 사용되지 않은 공간이 남아 있습니다.
다른 OS에서도 비슷한 일이 발생할 수 있다고 상상할 수 있습니다.
@kasperd 덕분에 추가 조사를 수행했으며 실제로 문제가되었습니다. 이 기능을 EWEOM (Early Warning End Of Media)이라고하며 테이프 제조업체가 테이프에 놓은 마커를 나타내므로 스풀 된 테이프 양을 추적하는 드라이브가 아닙니다.
mbuffer테이프에 쓰는 데 사용 하는 프로그램에 대한 패치 를 작성했으며 테이프 끝에 도달했을 때 ENOSPC번갈아 가면서 오류가 발생 write()하지만 더 많은 데이터를 계속 쓸 수 있습니다. 필자의 경우 압축 할 수없는 데이터의 압축에 따라 8 ~ 19GiB의 훨씬 더 많은 데이터가 있습니다.
흥미롭게도 EWEOM 마커에 도달하면 테이프 쓰기 속도가 크게 떨어집니다. 거의 80MB / sec에서 약 47MB / sec로 절반으로 줄어 듭니다. 이 시점 이전에 드라이브가 몇 시간 동안 80MB / 초를 유지했기 때문에 데이터 문제가 아닌 것 같습니다. 드라이브 모터가 느린 속도로 작동하는 것을들을 수 있으며 전체 테이프에 걸쳐 다시 쓰기를하면이 섹션이 다시 쓰여지더라도 속도가 증가하지 않습니다. 아주 새로운 테이프.)
테이프에 EWEOM 마커가 나타나는시기에 대한 설명서를 찾을 수 없으므로 표준화되었는지 확실하지 않습니다. 내가 찾을 수있는 것은 테이프 공간의 5 %로 증가한 LTO-6 / 7 드라이브에 대한 모호한 참조 일뿐입니다. 테이프의 빠른 쓰기 속도로 인해 큰 버퍼를 플러시 할 수 있습니다.
Linux API가 진행되는 한 관련 행은 st.c SCSI 테이프 드라이버 소스 코드 에 있으며이 동작에 대한 설명은 st드라이버 문서에 있습니다.