ZimaOS Files에서 약 600~650MB/s로 복사된다고 해서 NVMe 장치 자체가 SATA 속도로 제한된다는 의미는 아닙니다. 원본 커뮤니티 가이드는 원시 스토리지 처리량과 파일 복사 작업 처리량을 올바르게 구분합니다. 브라우저 기반 파일 관리자는 직접 벤치마크에서 측정하지 않는 메타데이터 처리, 진행률 추적, 안전 로직, 사용자 공간 복사, 파일 시스템 오버헤드 및 파일별 작업을 추가할 수 있습니다.
가장 유용한 방법은 비교 방식입니다. 대용량 순차 직접 I/O 작업으로 동일한 스토리지를 테스트한 다음, CLI와 Files를 통해 동일한 대용량 파일을 복사하세요. 원시/직접 테스트가 여러 GB/s인데 GUI 복사는 약 600MB/s에 머문다면 병목은 NVMe 장치보다 상위 계층에 있을 가능성이 큽니다.
파일 하나의 복사 수치만으로는 NVMe 벤치마크가 아닙니다
내부 복사 속도는 다음에 따라 달라집니다.
- 원본과 대상이 같은 장치인지 다른 장치인지;
- 파일 시스템 유형;
- 쓰기 시 복사 동작;
- 파일 크기와 파일 개수;
- CPU 오버헤드;
- 페이지 캐시;
- 복사 구현입니다.
어떤 작업에서는 600MB/s가 뛰어난 결과일 수 있지만, 다른 작업에서는 저조할 수 있습니다.
대규모 순차 테스트 파일로 시작하세요
대용량 파일은 메타데이터로 인한 잡음을 줄이고 지속 처리량을 더 쉽게 해석할 수 있게 합니다. 원본은 작업이 관찰할 수 있을 만큼 오래 실행되도록 10GB 파일을 사용했습니다.
대용량 테스트 파일을 만들기 전에 대상 스토리지에 충분한 여유 공간이 있는지 확인하세요. 시스템 디스크나 데이터 디스크를 가득 채우는 벤치마크는 다른 장애를 일으킬 수 있습니다.
원본은 직접 쓰기에 dd를 사용했습니다
커뮤니티 가이드에서는 다음을 제안했습니다.
dd if=/dev/zero of=/DATA/testfile bs=1G count=10 oflag=direct status=progressoflag=direct 쓰기 경로에서 페이지 캐시의 영향을 줄입니다. 대략적인 순차 쓰기 확인에 유용합니다.
모든 빌드, 장치 및 파일 시스템이 동일한 블록 크기나 직접 I/O 동작을 똑같이 지원한다고 가정하지 마세요.
원본 dd 읽기 테스트는 더 신중하게 해석하세요
그런 다음 원본은 파일을 다음으로 읽었습니다. /dev/null직접 I/O 읽기 옵션이나 캐시 제어가 없으면 최근에 사용한 파일의 일부가 페이지 캐시에서 제공되어 실제보다 읽기 속도가 빠른 것처럼 보일 수 있습니다.
신뢰할 수 있는 스토리지 비교를 위해 양방향에서 직접 I/O를 명시적으로 사용하는 도구/구성을 우선 사용하거나 캐싱의 영향을 파악해야 합니다.
fio가 더 신뢰할 수 있는 스토리지 벤치마크입니다
원본의 지속 쓰기 예제는 다음을 사용했습니다.
fio --name=nvme --filename=/DATA/fio.test --size=10G --rw=write --bs=1M --iodepth=32 --numjobs=1 --direct=1 --runtime=30 --group_reporting여전히 커뮤니티 가이드 수준이지만, 명시적인 테스트 크기, 순차 쓰기, 큐 깊이, 직접 I/O, 실행 시간 및 그룹화된 결과를 포함해 벤치마크 형식이 더 명확합니다.
실제 데이터가 들어 있는 원시 장치에 파괴적인 fio 작업을 절대 지정하지 마세요. 결과를 완전히 이해하고 있지 않다면 파일 시스템에 있는 일회용 테스트 파일을 사용하세요.
동일한 데이터 세트로 GUI와 CLI 비교
소스에서 제시하는 가장 중요한 방법론적 조언은 두 경우에 동일한 대용량 파일을 사용하는 것입니다.
- CLI 복사
- ZimaOS Files 복사
데이터 세트, 소스, 대상 및 파일 시스템이 동일하다면 차이는 복사 파이프라인을 더 직접적으로 반영합니다.
작은 파일은 훨씬 느릴 수 있습니다.
수천 개의 사진, 프로젝트 파일, 썸네일 또는 AppData 항목은 반복적인 열기/생성/메타데이터/체크섬 작업을 필요로 합니다. 매우 빠른 NVMe에서도 전체 전송 속도는 단일 대용량 동영상이나 ISO보다 훨씬 낮아질 수 있습니다.
Btrfs의 COW 및 메타데이터 동작은 정확한 작업에 따라 추가 오버헤드를 유발할 수 있습니다.
느린 복사가 실행되는 동안 CPU와 I/O를 확인하세요.
소스에서는 디스크 사용률과 CPU를 동시에 관찰할 것을 권장합니다. 목표는 다음 중 무엇인지 확인하는 것입니다.
- 디스크가 포화되었습니다.
- CPU 코어 하나가 병목입니다.
- 다른 프로세스가 I/O를 경합하고 있습니다.
- 복사 파이프라인이 스토리지를 구동하지 않고 대기하고 있습니다.
이는 Files 진행률 표시줄의 수치만 인용하는 것보다 더 유용한 정보입니다.
NVMe 속도는 PCIe 레인과 장치에 따라서도 달라집니다.
정상적인 NVMe도 다음과 같은 경우 광고된 수치보다 낮게 작동할 수 있습니다.
- 슬롯이 PCIe x4가 아니라 x1/x2입니다.
- 플랫폼이 PCIe Gen 4가 아니라 Gen 3입니다.
- SSD가 열로 인해 스로틀링되고 있습니다.
- 컨트롤러가 레인을 공유하고 있습니다.
- 지속적인 쓰기 중에 SLC 캐시가 소진되었습니다.
실제 벤치마크는 일반적인 “NVMe = 7GB/s” 기대치가 아니라 하드웨어 구성과 비교해야 합니다.
현재 IceWhale 전송 가이드도 UI 경로와 더 빠른 전송 경로를 구분합니다.
IceWhale의 ZimaCube Thunderbolt 가이드에서는 역사적으로 ZimaOS UI 전송 경로가 직접 Samba/Thunderbolt 경로보다 느리게 실행되는 것으로 나타났으며, 이는 파일 UI가 원시 또는 네트워크 스토리지 처리량과 동일하지 않다는 일반적인 점을 뒷받침합니다.
지원되는 네트워크 측 검사를 수행하고 느린 복사의 원인을 스토리지 하드웨어로 단정하기 전에 현재 ZimaOS 전송 문제 해결 체크리스트를 사용하세요.
완료 후 테스트 파일 삭제
대용량 dd/fio 파일은 수십 기가바이트를 빠르게 차지할 수 있습니다. 결과를 기록한 후 알려진 테스트 파일을 삭제하고, 이후 여유 공간을 확인하세요.
NVMe 벤치마크 FAQ
ZimaOS Files에서 600MB/s가 나온다고 해서 NVMe가 SATA 속도로 제한된다는 뜻인가요?
아니요. 이는 원시 NVMe 성능이 아니라 해당 복사 작업 흐름을 측정합니다.
dd 읽기가 비현실적으로 빠르게 보일 수 있는 이유는 무엇인가요?
최근에 작성된 파일은 읽기 테스트에서 캐시를 명시적으로 우회하지 않는 한 페이지 캐시에서 일부 제공될 수 있습니다.
GUI 복사 파이프라인을 비교하는 가장 좋은 방법은 무엇인가요?
CLI와 Files에서 동일한 소스와 대상, 동일한 대용량 데이터 세트를 사용한 다음 CPU와 스토리지 I/O를 모니터링하며 비교하세요.
