☰

dd의 bs가 100M에서 왜 그렇게 느린가요? [닫기]

tag-icon • tag-icon dd
dd의 bs가 100M에서 왜 그렇게 느린가요? [닫기]

방금 dd를 사용하여 빠른 SSD를 덮어쓰려고 했습니다. 내가 입력한 우분투 부팅 이미지를 사용하여:

dd if=/dev/zero of=/dev/sda bs=100M
error writing '/dev/sda': No space left on device
blah blah
256 GB copied, 1195.81 s 214 MB/s

이거 엄청 느린거 아냐? 그리고 병목 현상은 어디에 있습니까? 블록 크기 선택은 어떻습니까?

답변1

인간이 일반적으로 선호하는 최적의 블록 크기는 dd약 입니다 64k.256k1M

실제 I/O가 없는 벤치마크:

$ for bs in 512 4k 16k 64k 128k 256k 512k 1M 4M 16M 64M 128M 256M 512M
> do
>     echo ---- $bs: ----
>     dd bs=$bs if=/dev/zero of=/dev/null iflag=count_bytes count=10000M
> done
---- 512: ----
20480000+0 records in
20480000+0 records out
10485760000 bytes (10 GB) copied, 4.2422 s, 2.5 GB/s
---- 4k: ----
2560000+0 records in
2560000+0 records out
10485760000 bytes (10 GB) copied, 0.843686 s, 12.4 GB/s
---- 16k: ----
640000+0 records in
640000+0 records out
10485760000 bytes (10 GB) copied, 0.533373 s, 19.7 GB/s
---- 64k: ----
160000+0 records in
160000+0 records out
10485760000 bytes (10 GB) copied, 0.480879 s, 21.8 GB/s
---- 128k: ----
80000+0 records in
80000+0 records out
10485760000 bytes (10 GB) copied, 0.464556 s, 22.6 GB/s
---- 256k: ----
40000+0 records in
40000+0 records out
10485760000 bytes (10 GB) copied, 0.48516 s, 21.6 GB/s
---- 512k: ----
20000+0 records in
20000+0 records out
10485760000 bytes (10 GB) copied, 0.495087 s, 21.2 GB/s
---- 1M: ----
10000+0 records in
10000+0 records out
10485760000 bytes (10 GB) copied, 0.494201 s, 21.2 GB/s
---- 4M: ----
2500+0 records in
2500+0 records out
10485760000 bytes (10 GB) copied, 0.496309 s, 21.1 GB/s
---- 16M: ----
625+0 records in
625+0 records out
10485760000 bytes (10 GB) copied, 0.972703 s, 10.8 GB/s
---- 64M: ----
156+1 records in
156+1 records out
10485760000 bytes (10 GB) copied, 1.0409 s, 10.1 GB/s
---- 128M: ----
78+1 records in
78+1 records out
10485760000 bytes (10 GB) copied, 1.04533 s, 10.0 GB/s
---- 256M: ----
39+1 records in
39+1 records out
10485760000 bytes (10 GB) copied, 1.04685 s, 10.0 GB/s
---- 512M: ----
19+1 records in
19+1 records out
10485760000 bytes (10 GB) copied, 1.0436 s, 10.0 GB/s
  • 기본 512바이트 속도는 매우 느립니다(512바이트당 2개의 시스템 호출은 CPU에 너무 많은 양입니다).
  • 4k비교하다512
  • 16k비교하다4k
  • 64k-이미 256k최고
  • 512k- 4M조금 더 느려요
  • 16M-속도는 절반 512M, 그보다 더 나쁘다 4k.

내 생각엔 특정 크기부터 시작하면 동시성 부족으로 인해 속도가 떨어지기 시작하는 것 같습니다. dd는 단일 프로세스입니다. 동시성은 주로 커널에 의해 제공됩니다(미리 읽기, 캐시된 쓰기...). 100M을 쓰기 전에 100M을 읽어야 하는 경우 장치는 때때로 다른 장치가 읽기 또는 쓰기를 완료할 때까지 기다리며 유휴 상태가 됩니다. 블록 크기가 너무 작으면 엄청난 시스템 호출 오버헤드가 발생하지만 약 64k에서는 이것이 완전히 사라집니다.

동일한 장치에서 복사하거나 동일한 장치로 복사할 때 100M 이상의 블록 크기가 도움이 될 수 있습니다. 적어도 하드 드라이브의 경우 동시에 두 위치에 있을 수 없기 때문에 이렇게 하면 찾는 데 낭비되는 시간을 줄일 수 있습니다.

SSD를 이렇게 덮어쓰려는 이유는 무엇입니까? 일반적으로 SSD에 불필요한 쓰기를 피하려고 합니다. 사용된 모든 공간을 고려하면 다시 정리할 때까지 일부 성능이 저하될 수도 있습니다.

이 명령을 사용하여 전체 SSD를 정리/폐기할 수 있습니다.

blkdiscard /dev/sda

SSD에 hdparm -ITRIM 이후 결정론적 읽기 0이 있는 경우(해당 속성을 사용하여 확인할 수 있음) 0으로 가득 찬 것처럼 보이지만 SSD는 실제로 모든 블록을 사용 가능한 블록으로 처리하므로 최고의 성능을 제공합니다.

TRIM의 단점은 삭제된 파일을 폐기하면 데이터 복구 가능성을 모두 잃게 된다는 것입니다...

관련 정보