가끔 온라인에서 "기본값으로 'bs='를 설정하면 시간이 너무 오래 걸리기 때문에 꼭 설정하세요."와 같은 비과학적인 경험을 바탕으로 "이 방법은 다른 방법보다 시간이 더 오래 걸리는 것 같습니다."와 같은 댓글을 봅니다. "지난 주 시간"이 이를 확인하는 것 같습니다. 따라서 "dd"(보통 1-2GB 범위)를 사용할 때마다 지정된 값에서 복사한 온라인 가이드를 절반 정도 사용합니다. 나머지 시간에는 "fdisk -l" 목록에서 속도가 느린 것으로 생각되는 미디어(예: 쓰기 중인 SD 카드)에 대한 의미 있는 숫자를 선택합니다.
특정 상황(미디어 유형, 버스 크기 또는 기타 중요한 요소)에 대해 "최적" 값을 결정할 수 있는 방법이 있습니까? 판단하기 쉽나요? 그렇지 않다면 90-95% 목표를 달성할 수 있는 쉬운 방법이 있습니까? 아니면 "512보다 큰 것을 선택하세요"가 정답인가요?
이 실험을 직접 해볼 생각은 해봤지만 (손이 많이 든다는 점 외에도) 어떤 요인이 답에 영향을 미칠지 잘 모르겠어서 어떻게 하면 좋은 실험을 디자인할 수 있을지 모르겠습니다.
답변1
최적의 블록 크기를 결정하는 방법은 한 가지 뿐이며, 그것이 바로 벤치마크입니다. 방금 빠른 벤치마크를 수행했습니다. 테스트 머신은 커널 2.6.32와 coreutils 8.5를 갖춘 Debian GNU/Linux를 실행하는 PC입니다. 관련된 두 파일 시스템은 하드 디스크 파티션의 LVM 볼륨에 있는 ext3입니다. 소스 파일 크기는 2GB(정확히는 2040000kB)입니다. 캐싱 및 버퍼링을 활성화합니다. 나는 매 실행 전에 캐시 지우기를 사용합니다 sync; echo 1 >|/proc/sys/vm/drop_caches. 런타임에는 sync버퍼의 최종 플러시가 포함되지 않습니다. 최종 sync시간은 약 1초입니다.
실행은 same동일한 파일 시스템에 대한 복사본이고, 실행은 diff다른 하드 드라이브에 있는 파일 시스템에 대한 복사본입니다. 일관성을 위해 보고된 시간은 time유틸리티를 통해 얻은 벽시계 시간(초)입니다 . 각 명령을 한 번만 실행했기 때문에 시간에 얼마나 차이가 있는지 모르겠습니다.
same diff
t (s) t (s)
dd bs=64M 71.1 51.3
dd bs=1M 73.9 41.8
dd bs=4k 79.6 48.5
dd bs=512 85.3 48.9
cat 76.2 41.7
cp 77.8 45.3
결론적으로:더 큰 청크 크기(몇 메가바이트)가 도움이 되지만 크게 다르지는 않습니다(동일한 드라이브의 복사본에 대해 예상했던 것보다 훨씬 작음). 그리고 너무 형편없는 cat성과를 내지 마십시오. 이 숫자로는 문제를 일으킬 가치가 cp없다고 생각합니다 . dd함께 가세요 cat!
답변2
dd이전 IBM 메인프레임 테이프를 변환해야 했던 시절에는 블록 크기가 테이프에 쓰는 데 사용된 블록 크기와 일치해야 했습니다. 그렇지 않으면 데이터 블록이 건너뛰거나 잘렸습니다. (9트랙 테이프는 까다로웠습니다. 죽어서 다행입니다.) 이제 블록 크기는 장치 섹터 크기의 배수여야 합니다(보통 4KB이지만 최근 디스크에서는 훨씬 더 클 수 있으며 위의 경우 매우 작은 경우도 있습니다). 드라이브는 더 작을 수 있지만 어쨌든 4KB가 합리적인 중간 지점입니다.) 더 클수록 성능이 더 좋습니다. 나는 종종 하드 드라이브에서 1MB 블록 크기를 사용합니다. (요즘에는 작업할 메모리도 더 많아졌습니다.)
답변3
나는 동의한다긱 드래곤의 답변크기는 블록 크기의 배수여야 하며 일반적으로 4K입니다.
블록 크기를 찾으려면 stat -c "%o" filename아마도 가장 쉬운 옵션일 것입니다.
하지만 당신이 그렇게 한다고 말하면 dd bs=4K, 그것은 그렇게 된다는 뜻입니다 read(4096); write(4096); read(4096); write(4096)...
각 시스템 호출에는 약간의 오버헤드가 수반되는 컨텍스트 전환이 포함되며, I/O 스케줄러에 따라 분산된 쓰기가 포함된 읽기로 인해 디스크에서 많은 탐색이 수행될 수 있습니다. (이것은 Linux 스케줄러의 주요 문제는 아니지만 여전히 고려해 볼 가치가 있습니다.)
따라서 이렇게 하면 bs=8K디스크가 쓰기(또는 다른 프로세스에 대한 I/O 서비스)할 다른 위치를 찾기 전에 디스크에서 서로 가까이 있을 수 있는 두 블록을 동시에 읽을 수 있습니다.
그 논리에 따르면 bs=16K더 좋습니다.
그래서 제가 궁금한 것은 성능이 악화되기 시작하는 상한선이 있는지, 아니면 단지 메모리에 의한 제한인지입니다.
답변4
그렇지 않다면 90-95% 목표를 달성할 수 있는 쉬운 방법이 있습니까?
사용bs=1M
느린 USB2/3 플래시 드라이브, SD 카드, 하드 드라이브부터 NVMe SSD, RAM 전용 장치까지 85% 이상의 장치에 대해 95% 이상의 최고 성능을 제공합니다 /dev/zero.
원천?
내 머릿속에는 목소리가 있습니다.
또한 10년이 넘는 경험적 테스트와 의사과학적 벤치마킹 및 편향된 상식도 있습니다.
야, 네가 물어봤잖아단순한방법!