왜 dd가 너무 오래 걸립니까?


18

한 디스크를 다른 디스크에 복사해야합니다. 아래 명령으로 시도했는데 페데로에서 1TB의 디스크를 복사하는 데 거의 하루가 걸립니다.

dd if=/dev/sda of=/dev/sdb 

아래 명령을 사용하여 Unix (HP-UX) 시스템에서 동일하게 시도했으며 몇 시간 내에 완료됩니다.

dd if=/dev/sda of=/dev/rdsk

디스크에서 디스크로 더 빨리 복사하는 데 사용할 수있는 대안은 무엇입니까?


2
cp /dev/sda /dev/sdb또는 ( pv /dev/sda > /dev/sdb 진행률 표시 줄을 얻으려면) 훨씬 빠릅니다. 왜 dd여기서 사용 하겠습니까? dd단지 같은 것들에 유용 할 것이다 conv=sync,noerror오류가있는 핸들 디스크에 있지만, 그렇다하더라도 그것은처럼 사용하는 일에 더 많은 의미를 만들 것 ddrescue대신에 (또한 참조 pv-E옵션을).
Stéphane Chazelas

1
@ StéphaneChazelas cat는 더 빠를 수도 있지만 그 차이는 그다지 크지 않습니다 (실험에서와 같이 파일 대 파일보다 장치 대 장치의 경우 더 클 수 있음).
Gilles 'SO- 악마 중지

8
"유닉스 시스템에서 같은 것을 시도했습니다" -유닉스가 아닌 경우 어떤 시스템 유형에서 처음 시도 했습니까? 또한 어떤 하드웨어 등이 있습니까?
marcelm

에 오신 것을 환영합니다 dd# 1 함정
드미트리 Grigoryev

HP-UX (Integrity 블레이드)에서 처음 사용되었고 이전에는 Solaris 시스템도 사용되었습니다.
KKD

답변:


28

dd많은 (이상한) 옵션이 있습니다 ( dd (1) 참조 ) .

버퍼 크기를 명시 적으로 명시해야합니다.

dd if=/dev/sda of=/dev/sdb bs=16M

IIRC, 기본 버퍼 크기는 512 바이트입니다. 위의 명령은 16MB로 설정합니다. 더 작은 것을 시도 할 수 bs=1M있지만 (예 :) 기본값보다 많은 것을 사용해야합니다 (특히 4Kbytes의 섹터가있는 최신 디스크 하드웨어, 즉 Advanced Format ). 나는 적어도 메가 바이트 인 2의 힘을 순진 히 추천합니다.

기본 512 바이트 버퍼 크기를 사용하면 하드웨어 가 커널이 각 512 바이트 블록마다 4K를 전송해야 한다고 생각합니다 (그러나 매우 틀릴 수 있습니다) .

에 관해서 rdskSD (4) 매뉴얼 페이지 말한다 :

현재는 블록 장치 만 제공됩니다. 원시 장치는 아직 구현되지 않았습니다.

dd의 버퍼 크기가 증가하면 읽기 및 쓰기 작업 성능이 향상됩니다. 이제 모든 디스크에는 하드웨어 읽기 / 쓰기 버퍼가 있습니다. 그러나 하드웨어 버퍼보다 ​​dd의 버퍼 크기를 늘리면 두 번째 디스크가 자체 하드웨어 버퍼에서 모두 쓰여질 때 dd가 첫 번째 디스크에서 버퍼로 읽히기 때문에 성능이 저하됩니다. bs장치마다 다른 값을 가질 때마다 dd 명령의 옵션을 설정해야 합니다.


Linux 시스템에서 rdsk를 사용할 수 있는지 여부 나는 유닉스 시스템에서 사용했다.
KKD

1
페이지 캐시는 사용자가 무엇을하든 4Kb 블록을 처리하지만 dd가 해당 4Kb를 읽는 데 사용하는 syscall 수를 제어 할 수 있습니다. 쓰기 쓰기 지연 비용이 저장된 syscall보다 비싸지 만 일부 스팟이 어디에 있는지 전혀 알지 못하는 읽기 크기가 있다고 확신합니다.
쓸모없는

몇 MB의 블록 크기는 더 나은 기본 512B보다하지만 내가 벤치마킹 때 나는 그 발견 cat단지뿐만 아니라 (파일 시스템 간 파일 시스템 전송, 직접 블록에 블록 서로 다른 성능 특성을 가질 수있다)했다. 그러나 어떤 경우에도 그 차이는 크지 않았습니다.
Gilles 'SO- 악마 그만

1
흥미롭게도 macOS (SUS 인증, btw)에서 수행 할 때 대상 으로 사용/dev/rdiskX 하는 것이 더 빠릅니다dd .
adib

1
내가하고있는 것처럼 진행되는 일이 궁금하다면 status=progress모든 작업 진행 상황을 인쇄합니다.
Aleksander Lech

17

유닉스 랜드에서 몇 년 전은 dd블록 장치를 복사하는 데 필요한 방법이었습니다. 비록 적어도 리눅스 기반 시스템에서는 cat거의 항상보다 빠르지 만화물 컬트 지식으로 발전했습니다 dd.

그러나 역사상으로도 상당한 블록 크기는 각 시스템 호출이 I / O 작업을 트리거 한 경우 (느린) 시스템 호출 수를 줄이는 데 도움이되었습니다. 기본 블록 크기는 512 바이트 (하나의 디스크 섹터)입니다. 여러 디스크 블록을 단일 읽기로 함께 수집하는 것도 가능합니다. 이 예는 32MB 블록 크기를 사용합니다.

dd bs=$((512*2048*32)) if=/dev/source of=/dev/target

그러나 현재 Linux 기반 시스템에서는 디스크를 간단한 방법으로 가장 효율적으로 복사 할 수 있습니다 cat

cat /dev/source >/dev/target

(질문에 대한 의견에서 언급 한 바와 같이 진행 상황과 처리량을 pv대신 할 수 있습니다 cat.)


3
특히 dd를 사용해야하는 이유는 GNU cp의 버그와 90 년대 초반의 리눅스 커널의 버그였습니다. 과거 유닉스 시스템에서 dd를 사용하는 이유는 매우 달랐으며 전체 블록 장치를 복사하려는 것은 드문 일이었습니다.
Random832

1
@ Random832 전체 디스크를 복사하려는 경우는 드문 일이지만, 주변 파티션을 복사해야한다는 것을 기억합니다 (큰 디스크-150 또는 200MB)
roaima

3
(버그의 세부 사항 : 커널은 디스크 사용 크기를 잘못보고했으며 [cp는 모든 소스 파일이 희소 파일이라고 결론 내 렸습니다.] cp는 희소 파일에서 장치 대상으로 복사 할 때 블록을 제로화하지 않았습니다. 소스의 블록은 쓰레기가 이미 디스크에있을 때 발생합니다)
Random832

나는 이런 종류의 대답을 좋아합니다. 정보 주셔서 감사합니다. 여기 updoot가 있습니다.
catbadger

7

일반적으로 dd일부 대안을 선호하여 피할 수 있습니다. ddrescue대신 GNU를 사용해야하는 몇 가지 이유가 있습니다 . 우분투에서는 다음과 같이 설치할 수 있습니다.

sudo apt-get install gddrescue

ddrescue사용하기에 평범 합니다. 패키지 이름과 달리 실행 파일 에는 초기 이름 이 없습니다g .

그것을 사용하는 것은 간단합니다 :

ddrescue inputFile outputFile logFile

로그 파일 (선택한 이름)을 사용하면 이전 작업을 다시 수행하지 않고도 일시 중지 / 중지 및 재시작 할 수 있습니다. 이는 큰 복제 또는 디스크 복구를 수행 할 때 유용합니다. 기본적으로 진행률, 현재 복사 속도, 평균 복사 속도 및 불량 블록 수를 표시합니다.

그것은 블록 크기에 합리적인 기본값을 사용하므로 적어도 경험상 장치가 처리 할 수있는 속도만큼 복사 속도가 항상 빠릅니다 (모든 크기와 유형으로 수백 개의 드라이브를 복제했습니다).

종종 고장이 나기 시작하는 드라이브에는 가끔 속도 저하, 낮은 평균 속도, 갑자기 긴 일시 정지 (나쁜 섹터) 또는 완전한 재설정 (심각한 표면 오류)과 같은 속도 문제가 있습니다. ddrescue드라이브 자체가 재설정 되더라도 위의 모든 사항을 식별하고 복제본 (로그 파일을 지정한 경우)을 다시 시작하는 데 도움이 될 수 있습니다.


6

아주 좋은 질문입니다. 원시 인터페이스는 일부 유닉스 시스템 (tru64, hpux, solaris)에서 구현되지만 Linux에서는 구현되지 않습니다. 원시 인터페이스는 유닉스 I / O를 건너 뛰기 때문에 더 빨리 전송합니다. 블록 인터페이스 ( /dev/dsk또는 /dev/disk)는 유닉스 I / O 시스템을 사용하기 때문에 속도가 느립니다. 속도를 높이려면 dd(gnu dd can) 사용 bs=30M하거나 bs=20Mhw에 따라 다릅니다. 짧은 대답은 : 아니요 적어도 아는 한 구현되지 않았습니다. 커널 2.2 이전 버전부터 리눅스를 rdsk사용하고 있으며 유닉스 에서는 결코 사용 되지 않았습니다 .


6
왜 2의 거듭 제곱이 아닌 블록 크기를 제안합니까?
Basile Starynkevitch

2
@Basile의 디스크 블록 크기는 여러 개이면 충분하므로 20MiB가 좋습니다.
roaima
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.