이 소스 스레드에서 가장 강력한 근거는 600MB/s의 Files 스크린샷이 아니라, 이후에 진행된 직접 스토리지 테스트입니다. ZimaOS WebUI 복사 속도가 약 600~650MB/s에 머물던 한 사용자는 dd로 직접 쓰기 속도 약 2.3GB/s, fio로 쓰기 속도 약 2.2GB/s를 측정했습니다. 이는 해당 시스템에서 OS 전체적으로 “NVMe가 SATA III 속도로 제한된다”는 설명을 배제합니다.
따라서 더 타당한 결론은 느린 수치가 내부 Files 복사 워크플로 또는 메타데이터, Btrfs CoW, 버퍼링, 단일 스레드 제한과 같은 복사 작업의 영향에서 비롯되었으며, 물리적인 NVMe 경로 자체의 문제가 아니라는 것입니다.
소스에서는 여러 복사 경로에서 동일한 제한이 재현되었습니다
Dave는 단일 NVMe에서 NVMe로 복사하는 경우, NVMe에서 RAID0으로 복사하는 경우, RAID0에서 단일 NVMe로 복사하는 경우, 10GbE 워크플로에서 비슷한 동작이 나타났다고 보고했습니다. 이후 다른 사용자는 Windows에서 ZimaOS로 SMB 복사를 하면 10GbE의 최대 속도에 도달할 수 있지만, 내부 Files 복사는 여전히 약 650MB/s에 머문다고 말했습니다.
직접 dd 쓰기에서 약 2.3GB/s에 도달했습니다
소스에서는 dd if=/dev/zero of=/DATA/testfile bs=1G count=10 oflag=direct status=progress를 사용했으며, SATA III의 실제 처리량보다 훨씬 높은 약 2.3GB/s의 결과를 게시했습니다.
fio에서도 약 2.2GB/s에 도달했습니다
소스의 fio 실행 결과는 약 2163MiB/s / 2268MB/s의 쓰기 속도를 보고했습니다. 선택한 동기화 엔진이 큐 깊이를 사실상 1로 제한했음에도, 이 결과는 스토리지 스택이 Files 복사 수치보다 몇 배나 높은 속도를 낼 수 있음을 보여 주었습니다.
소스의 dd 읽기 수치는 신중하게 해석해야 합니다
소스에서는 새로 작성한 테스트 파일을 /dev/null로 읽을 때 약 3.0GB/s도 측정했습니다. 이 읽기 작업에서는 직접 I/O나 페이지 캐시 플러시를 명시적으로 사용하지 않았으므로 캐시가 수치에 영향을 주었을 수 있습니다.
전체 CPU 사용량이 낮아도 단일 스레드 병목을 배제할 수 없습니다
사용자 공간 복사 파이프라인은 여러 코어가 있는 시스템에서 전체 CPU 사용량이 낮게 보이는 동안에도 한 코어를 포화시킬 수 있습니다. 느린 Files 복사 중에는 스레드별 CPU 사용량과 디스크 사용률을 모니터링하세요.
CLI와 Files에서 동일한 대용량 파일을 비교하세요
Files 복사와 CLI 복사에 동일한 소스, 대상, 대용량 테스트 파일을 사용한 다음, 삭제 가능한 직접 I/O 벤치마크와 비교하세요. 이렇게 하면 UI/백엔드 복사 오버헤드와 원시 장치 성능을 분리할 수 있습니다.
파일 수와 Btrfs 메타데이터가 실제 복사 속도를 바꿀 수 있습니다
수천 개의 작은 파일을 복사하려면 메타데이터 작업을 반복해야 하며, Btrfs의 CoW 동작은 내부 복사 비용을 바꿀 수 있습니다.
이를 현재 ZimaOS의 보편적인 속도 제한이라고 부르지 마세요
소스는 여러 시스템에서 과거 Files/내부 복사 병목이 발생했다는 강력한 근거를 제공합니다. 그러나 현재 ZimaOS 1.7.1에서도 모든 하드웨어 및 파일 시스템 조합에서 정확히 동일한 상한이 적용된다는 점까지 입증하지는 않습니다.
내부 복사에서는 동일한 스토리지를 동시에 읽고 쓸 수 있습니다
소스와 대상이 동일한 물리적 NVMe 또는 동일한 RAID 풀에 있다면, 드라이브는 읽기와 쓰기를 동시에 처리해야 합니다. 따라서 표시되는 복사 처리량은 단방향 순차 쓰기 벤치마크와 비교할 수 없습니다.
결과를 비교하기 전에 물리적인 소스 장치와 대상 장치를 기록하세요. “내부 복사”는 소프트웨어 경로를 의미할 뿐, 반드시 서로 독립된 두 SSD를 뜻하지는 않습니다.
마케팅 수치를 비교하기 전에 PCIe 링크 폭과 세대를 확인하세요
고성능 NVMe도 PCIe x1/x2 링크, 구형 세대, 칩셋 레인 공유, 또는 물리적 커넥터 크기와 다르게 연결된 플랫폼 슬롯 때문에 제한될 수 있습니다. 원시 벤치마크에서 2GB/s 이상에 도달한다면 600MB/s 상한은 배제할 수 있지만, 합리적인 토폴로지상의 이유로 데스크톱 사양에 표시된 SSD 최대 속도보다 낮을 수는 있습니다.
지속적인 복사에서는 SSD의 발열 또는 SLC 캐시 제한이 발생할 수 있습니다
짧은 벤치마크와 장시간 파일 복사는 SSD에 서로 다르게 부하를 줍니다. 드라이브는 처음에는 매우 빠르게 작동하다가 의사 SLC 캐시가 가득 차거나 온도가 상승하면 속도가 떨어질 수 있습니다. 모든 속도 저하를 Files의 문제로 판단하기 전에 충분히 긴 시간 동안 NVMe 온도와 지속 처리량을 모니터링하세요.
페이지 캐시 때문에 일부 테스트가 장치보다 빠르게 보일 수 있습니다
소스의 직접 쓰기 결과는 직접 I/O를 사용했기 때문에 강력한 근거입니다. 그러나 쓰기 직후 수행한 읽기 테스트는 벤치마크에서 페이지 캐시를 명시적으로 우회하지 않는 한 메모리 캐시의 영향을 받을 수 있습니다.
반복 가능한 비교를 위해 직접 I/O가 활성화되어 있는지 명시하는 벤치마크 구성을 사용하고, 캐시로 인한 왜곡을 줄일 수 있도록 테스트 파일을 충분히 크게 설정하세요.
600MB/s를 고정된 제품 한계로 보기 전에 현재 Files 파이프라인을 다시 테스트하세요
이 스레드는 현재 릴리스 이전의 ZimaOS 버전을 다룹니다. 오늘날에도 Files가 제한된 것처럼 보인다면 동일한 대용량 파일, 동일한 소스와 대상, 현재 CLI/직접 I/O 비교를 사용해 재현하세요. 이렇게 해야 오래된 수치상의 상한을 계속 답습하는 대신 실행 가능한 근거를 얻을 수 있습니다.
NVMe 속도 FAQ
소스에서 ZimaOS가 NVMe를 SATA 속도로 제한한다는 사실을 입증했나요?
아니요. 동일한 시스템에서 직접 dd 및 fio 쓰기 속도가 2GB/s를 초과했습니다.
소스에서 가장 강하게 지목한 원인은 무엇인가요?
NVMe 장치 자체보다는 내부 WebUI/파일 관리자 복사 파이프라인 또는 작업 오버헤드입니다.
새로 작성한 dd 읽기 결과를 순수한 디스크 속도로 봐야 하나요?
반드시 그렇지는 않습니다. 직접 읽기 I/O나 캐시 제어가 없으면 페이지 캐시가 결과에 영향을 줄 수 있습니다.
