dd 명령으로 확인하면서 디스크 쓰기 차이가 너무 많이 존재하는 이유 without bs와with bs

dd if = / dev / zero of = / tmp / test.log count = 100000000

100000000+0 records in
100000000+0 records out
51200000000 bytes (51 GB) copied, 289.564 s, 177 MB/s

dd if = / dev / zero of = / tmp / test1.log bs = 1G count = 50 oflag = dsync

50+0 records in
50+0 records out
53687091200 bytes (54 GB) copied, 150.427 s, 357 MB/s

100000000+0 records in
100000000+0 records out
51200000000 bytes (51 GB) copied, 288.614 s, 177 MB/s

50+0 records in
50+0 records out
53687091200 bytes (54 GB) copied, 109.774 s, 489 MB/s

나는 고글을 옮겼 지만 구체적인 예를 얻지 못했지만 여기 에는 좋은 동굴이 거의없는 좋은 기사가 있습니다.

linux hard-drive dd

— 칸 쿠마르
소스

/ tmp의 파일 시스템은 무엇입니까? 거의 다 찼습니까? 회전하는 하드 드라이브, USB 플래시, SSD? 각 테스트 전에 디스크 캐시를 지우셨습니까? 다른 프로그램이 같은 드라이브 나 다른 드라이브를 읽거나 쓸 수 없었습니까?

— Xen2050

@ Xen2050, 죄송합니다. 디스크 기반의 파일 시스템은 거의 1TB의 공간 중 700GB가 비어 있습니다.

— Karn Kumar

bs매개 변수 dd가 없으면 장치의 표준 블록 크기 (대개 512 바이트)가 사용됩니다. 즉,

512 바이트의 페이로드마다 요청 오버 헤드가 발생합니다.
512의 블록 크기가 장치에 대한 최적의 블록 크기가 아닌 경우 (예 : 512 에뮬레이션 또는 SSD가있는 4K 섹터) 장치를 최적의 작업 지점에서 멀리 떨어 뜨립니다.

하드웨어에 따라 bs장치 캐시에 맞을 수록 더 작은 숫자로 더 나은 숫자를 얻을 수 있습니다 . 예를 들어 1GB 캐시가있는 RAID 컨트롤러의 경우 10MB 블록 크기를 시도 할 수 있습니다.

— 유겐 리크
소스

이것은 실제 문제에 대한 훌륭한 대답이며 실질적인 배경입니다.

— Karn Kumar