bs 매개 변수의 최적 값을 dd로 결정하는 방법이 있습니까?

"저는 기본값이 너무 오래 걸리기 때문에 'bs ='를 설정했는지 확인하십시오"라는 라인과 온라인에서 의견을 보았습니다. 지난 주에 " 따라서 'dd'(일반적으로 1-2GB 범위)를 사용할 때마다 bytes 매개 변수를 지정해야합니다. 복사하는 온라인 안내서에 지정된 값을 사용하는 시간의 약 절반 나머지 시간에는 'fdisk -l'목록에서 의미가있는 숫자를 선택하여 느린 미디어 (예 : 내가 쓰는 SD 카드)입니다.

주어진 상황 (미디어 유형, 버스 크기 또는 기타 중요한 사항)에 대해 "최상의"값을 결정하는 방법이 있습니까? 결정하기 쉬운가? 그렇지 않은 경우 90-95 %의 쉬운 방법이 있습니까? 아니면 정답 일지라도 "512보다 큰 것을 골라야"하는가?

나는 실험을 직접 시도하려고 생각했지만 (많은 작업 외에도) 어떤 요인이 답에 영향을 미치는지 잘 모르겠으므로 좋은 실험을 디자인하는 방법을 모르겠습니다.

dd이전 IBM 메인 프레임 테이프를 변환해야했던 날짜부터 시작하여 블록 크기가 테이프를 쓰는 데 사용 된 크기와 일치해야하거나 데이터 블록을 건너 뛰거나 잘 렸습니다. (9 트랙 테이프는 까다로 웠습니다. 오래 전에 죽어 다행입니다.) 요즘 블록 크기는 장치 섹터 크기의 배수 여야합니다 (보통 4KB이지만 최근 디스크에서는 훨씬 더 크고 작은 엄지 손가락으로 표시 될 수 있음) 드라이브 크기는 더 작을 수 있지만 4KB는 중간 수준에 관계없이 합리적인 수준이며 성능이 클수록 좋습니다. 나는 종종 하드 드라이브에 1MB 블록 크기를 사용합니다. (요즘에는 더 많은 메모리를 버릴 수 있습니다.)

최적의 블록 크기를 결정하는 한 가지 방법이 있으며 이는 벤치 마크입니다. 방금 빠른 벤치 마크를 만들었습니다. 테스트 머신은 커널 2.6.32 및 coreutils 8.5와 함께 데비안 GNU / 리눅스를 실행하는 PC입니다. 관련된 두 파일 시스템은 하드 디스크 파티션의 LVM 볼륨에서 ext3입니다. 소스 파일은 2GB입니다 (정확히 2040000kB). 캐싱 및 버퍼링이 활성화되었습니다. 각 실행 전에으로 캐시를 비 웁니다 sync; echo 1 >|/proc/sys/vm/drop_caches. 런타임에는 sync버퍼를 플러시 하는 최종 단계 가 포함되지 않습니다 . 마지막 sync은 1 초 정도 걸립니다. same실행은 동일한 파일 시스템에 복사했다; diff실행은 다른 하드 디스크에있는 파일 시스템에 복사했다. 일관성을 위해보고 된 시간은time유틸리티 (초) 각 명령을 한 번만 실행했기 때문에 타이밍에 얼마나 많은 차이가 있는지 모릅니다.

             same   diff
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!

나는 크기가 블록 크기의 배수가되어야한다는 geekosaur에 동의하는데, 이는 종종 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더 좋습니다.

그래서 내가 알고 싶은 것은 성능이 악화되기 시작하는 상한이 있거나 메모리에 의해서만 제한되는 경우입니다.

질이 말했듯이, 당신은을위한 최적의 매개 변수를 확인할 수 있습니다 학사 하는 옵션 dd는 벤치마킹에 의해합니다. 그러나 이것은 다음과 같은 질문을 제기합니다. 어떻게이 매개 변수를 편리하게 벤치마킹 할 수 있습니까?

이 질문에 대한 임시 답변은 다음과 같습니다. dd-opt 사용 , 최근 에이 문제를 정확하게 해결하기 위해 노력한 유틸리티 :)

에서 가장 잘 작동하는 것 같은 sdcard 리더 usb2.0에 최적화되었습니다 bs=10M. 나는 8-10M 후에 개선없이 4M, 최대 16M에 시도했다. 전송 속도 측정이 어떻게 저하되는지 확인할 수 있습니다. 장치에 버퍼를로드 한 다음 장치가 실제 매체로 전송 될 때까지 기다릴 가능성이 높습니다.

angstrom/sdcard# dd if=/dev/zero of=/dev/sdb bs=10M
123+0 records in
123+0 records out
1289748480 bytes (1.3 GB) copied, 21.4684 s, 60.1 MB/s
341+0 records in
341+0 records out
3575644160 bytes (3.6 GB) copied, 117.636 s, 30.4 MB/s
816+0 records in
816+0 records out
8556380160 bytes (8.6 GB) copied, 326.588 s, 26.2 MB/s
955+0 records in
955+0 records out
10013900800 bytes (10 GB) copied, 387.456 s, 25.8 MB/s