위의 질문처럼 7zip(특히 Linux의 p7zip)은 아카이브를 테스트하는 동안 디스크 공간을 사용합니까? 작업할 수 있는 드라이브가 2TB 드라이브뿐이고 크기가 800GB~1TB에 이르는 모든 아카이브를 가지고 있기 때문에 하나가 아닌 2개의 아카이브를 동시에 테스트하려고 생각했습니다.
7zip 공식 문서에는 테스트 중 디스크 사용량에 대한 언급이 없습니다.
답변1
그러면 안됩니다. (그러나 그럴 수도 있다)
압축을 풀 때 아카이브의 데이터가 올바른지 확인하기 위해 모든 파일이나 데이터 블록에는 이와 관련된 CRC 또는 오류 감지 코드가 있습니다.
파일 압축을 풀 때 효율성 측면에서 오류 검사를 수행하는 것이 합리적입니다.~ 전에디스크에 데이터를 쓰는 중입니다. 그렇지 않으면 아카이브에서 읽고 디스크에 쓴 다음 오류 검사를 위해 디스크에 있는 데이터를 다시 읽는 귀중한 리소스를 낭비하게 됩니다. 대규모 아카이브 또는 메모리가 제한된 시스템에서는 허용되지 않는 파일의 압축을 푸는 데 걸리는 시간이 두 배로 늘어날 수 있습니다. 이 경우 디스크 읽기 및 쓰기가 프로세스에서 가장 느린 부분이라고 가정합니다.
쓰기 전에 검사를 수행하면 압축 해제기를 통해, 오류 검사 알고리즘을 통해 아카이브를 효과적으로 스트리밍한 다음 디스크로 내보내고 디스크 하위 시스템이 수행 중인 작업을 알고 있다고 가정할 수 있습니다. 작업이 완료되었습니다.
이런 방식으로 "테스트"하면 아카이브가 무료로 작동됩니다. 압축 해제와 정확히 동일한 단계를 따르지만 데이터를 디스크에 쓰지 않고 그냥 버립니다.
나는 이것이 작동하는 방식이라고 강력히 기대합니다. 왜냐하면 단순히 아카이브를 테스트하기 위해 모든 것을 디스크에 쓰는 것은 미친 것처럼 보이고 데이터의 "실제" 압축 해제보다 빠르지 않기 때문입니다. "테스트"가 더 빠르다는 것은 디스크에 데이터를 쓸 가능성이 가장 높은 최소 한 단계를 건너뛴다는 의미입니다.
답변2
아니요, 그렇지 않습니다. 적어도 19.00 버전은 아닙니다.
여러 파일을 병렬로 테스트하는 것은 솔리드 스테이트 드라이브에서 잘 작동하지만 일반적으로 기계식 드라이브에서는 성능이 저하됩니다. 그런 다음 여러 아카이브를 병렬로 읽으려면 많은 검색이 필요합니다. 따라서 다음과 같은 권고사항이 제시될 수 있습니다:
솔리드 스테이트 드라이브(NVMe 또는 SATA SSD)에서 아카이브를 테스트할 때 코어가 있는 만큼 많은 프로세스를 실행하십시오(가능한 경우).
동일한 기계적 드라이브(또는 기계적 RAID 볼륨)에서 아카이브를 테스트할 때 하나 또는 최대 두 개의 프로세스를 실행하십시오.
USB 드라이브의 아카이브를 테스트할 때 결과는 다양합니다.
안타깝게도 일반적인 USB "펜 드라이브" 또는 "스틱"의 대부분은 읽을 때에도 엄청나게 느립니다. 즉, USB 인터페이스 대역폭을 포화시키지 못합니다. 일부 드라이브는 드라이브의 서로 다른 여러 영역에서 동시에 데이터에 액세스할 때 속도가 더욱 느려집니다. 이는 디스크 컨트롤러의 RAM이 제한되어 있기 때문에 발생합니다. 컨트롤러는 RAM의 드라이브 전체에 한 번에 액세스하는 데 필요한 모든 메타데이터를 수용할 수 없으며 드라이브의 읽기 영역을 변경할 때 플래시 미디어에서 메타데이터를 다시 읽어야 하며 종종 링크 체인을 따라가야 합니다. 그것을 찾아라. 이러한 메타데이터 읽기는 플래시 메모리 레이아웃이 허용하더라도 드라이브에서 병렬화되지 않는 경우가 많으며 속도가 느린 전용 코드 경로를 사용하여 구현되는 경우도 많습니다.
이를 처리하는 유일한 확실한 방법은 대역폭 테스트를 수행하는 것입니다. a, b, c, d, e및 의 아카이브를 f모두 크기 기준으로 대략 동일한 순서로 확인해야 한다고 가정합니다 . 크기별로 내림차순으로 정렬해야 합니다. 먼저 의 검증 시간을 측정 a하고 대역폭을 계산합니다 BW_a = time_a / size_a. 그런 다음 b및 검증을 c병렬로 수행하고 해당 대역폭을 계산합니다. 그 합이 보다 sum_BW_bc크면 BW_a성능이 향상됩니다. 그런 다음 해당 대역폭 을 확인 d하고 병렬로 계산합니다. 그 합이 보다 크면 성능이 향상됩니다. 등등. 결국 이전 테스트에 비해 총 대역폭이 떨어지는 스트림 수에 도달하게 됩니다. 이전의 더 적은 수의 스트림을 사용하여 나머지 아카이브를 계속 확인합니다.efsum_BW_defsum_BW_bc
이 방법은 모든 드라이브에 적용할 수 있지만 기계식 드라이브의 성능 저하가 너무 심해서 확인 프로세스의 전체 성능에 과도한 영향을 미칠 수 있습니다. 따라서 병렬 테스트는 대역폭이 이전 단계 대역폭의 90% 미만인 것으로 확인되면 종료되어야 합니다. 테스트가 실행되는 매초마다 대역폭을 다시 계산하고 대역폭이 컷오프 지점 아래로 떨어지면 테스트를 종료하면 됩니다.