. dd if=/dev/urandom of=file bs=1M count=1000000이제 진행 상황을 확인 kill -SIGUSR1 <PID>하고 다음을 얻습니다.
691581+0 Datensätze ein
691580+0 Datensätze aus
725174190080 Bytes (725 GB) kopiert, 86256,9 s, 8,4 MB/s
800950+1 Datensätze ein
800950+0 Datensätze aus
839856947200 Bytes (840 GB) kopiert, 99429,5 s, 8,4 MB/s
dd: warning: partial read (809620 bytes); suggest iflag=fullblock
803432+1 Datensätze ein
803431+1 Datensätze aus
842459273876 Bytes (842 GB) kopiert, 99791,3 s, 8,4 MB/s
경고를 해석할 수 없습니다. 그것은 무엇을 말하는가? 경고 후 내 파일이 정말 무작위인가요, 아니면 문제가 있나요? +0 또는 +1은 무엇을 의미 800950+1 Datensätze ein하나요 800950+0 Datensätze aus? 경고 후에는 +1입니다. 오류 횟수입니까?
답변1
요약: dd올바르게 사용하기 어려운 까다로운 도구입니다. 그렇게 말하는 수많은 튜토리얼에도 불구하고 그것을 사용하지 마십시오. dd"유닉스 스트리트 신임" 분위기가 붙어 있습니다. 하지만 자신이 하고 있는 일을 진정으로 이해한다면 10피트 기둥으로 건드리면 안 된다는 것을 알게 될 것입니다.
dd블록당 시스템 호출 을 한 번 호출합니다 read( 값으로 정의됨 bs). 다음과 같은 보장은 없습니다.read 시스템 호출이 지정된 버퍼 크기만큼의 데이터를 반환한다는 . 이는 일반 파일 및 블록 장치에서는 작동하는 경향이 있지만 파이프 및 일부 문자 장치에서는 작동하지 않습니다. 보다dd는 언제 데이터 복사에 적합합니까? (또는 read() 및 write()가 부분적인 경우)자세한 내용은. read시스템 호출이 하나의 전체 블록보다 작은 값을 반환 하면 dd부분 블록을 전송합니다. 여전히 지정된 수의 블록을 복사하므로 전송된 총 바이트 양은 요청한 것보다 적습니다.
"부분 읽기"에 대한 경고는 정확히 다음과 같이 알려줍니다. 읽기 중 하나가 부분적이어서 dd불완전한 블록이 전송되었습니다. 블록 수에서 는 +1한 블록이 부분적으로 읽혔음을 의미합니다. 출력 개수가 이므로 +0모든 블록이 읽기로 기록되었습니다.
이는 데이터의 무작위성에 영향을 주지 않습니다. 쓰는 모든 바이트는 dd에서 읽은 바이트입니다 /dev/urandom. 하지만 예상보다 적은 바이트를 얻었습니다.
Linux는 /dev/urandom임의의 대규모 요청을 수용합니다(출처:extract_entropy_userdrivers/char/random.c) 이므로 dd읽을 때 일반적으로 안전합니다. 그러나 많은 양의 데이터를 읽으려면 시간이 걸립니다. 프로세스가 신호를 받으면 read출력 버퍼를 채우기 전에 시스템 호출이 반환됩니다. 이는 정상적인 동작이며 애플리케이션은 read루프를 호출해야 합니다. dd역사적인 이유로 이 작업을 수행하지 않습니다( dd의 기원은 불분명하지만 특별한 요구 사항이 있는 테이프에 액세스하는 도구로 시작된 것으로 보이며 범용 도구로 적용되지 않았습니다). 진행 상황을 확인하면 dd읽기를 중단하는 신호가 프로세스에 전송됩니다. dd총 복사할 바이트 수를 아는 것(중단하지 마십시오. 진행 확인 없음, 일시 중지 없음) 또는 지금까지 복사한 바이트 수를 아는 것 중에서 선택할 수 있습니다 dd. 이 경우 추가 바이트 수는 알 수 없습니다. 바이트가 복사됩니다.
버전ddGNU coreutils에서(비임베디드 Linux 및 Cygwin에서 발견됨)에는 루프(및 에 대해서도 마찬가지 ) 를 호출하여 항상 전체 블록을 전송 하도록 fullblock지시하는 플래그가 있습니다 . 오류 메시지는 이를 사용하라고 제안합니다. 매우 특수한 상황(주로 테이프에 액세스할 때)을 제외하고는 항상 입력 및 출력 플래그 모두에서 사용해야 합니다. 전혀 사용하지 않는다면 일반적으로 더 나은 솔루션이 있습니다(아래 참조).ddreadwritedd
dd if=/dev/urandom iflag=fullblock of=file bs=1M count=1000000
수행할 작업을 확인하는 또 다른 가능한 방법은 블록 크기 1을 전달하는 것입니다. 그런 다음 블록 수에서 복사된 바이트 수를 알 수 있지만 첫 번째 블록을 읽기 전에 dda가 중단되면 어떻게 될지는 잘 모르겠습니다. read바이트(실제로는 가능성이 높지 않지만 발생할 수 있음). 그러나 작동하더라도 매우 느립니다.
사용에 대한 일반적인 조언은 dd다음과 같습니다.사용하지 마세요dd. 종종 장치에 액세스하기 위한 낮은 수준의 명령으로 광고 되지만 dd실제로는 그렇지 않습니다. 모든 마법은 장치 파일( /dev/…) 부분 에서 발생하며 dd오용으로 인해 데이터 손실이 발생할 가능성이 높은 일반 도구일 뿐입니다. . 대부분의 경우 적어도 Linux에서는 원하는 작업을 수행하는 더 간단하고 안전한 방법이 있습니다.
예를 들어, 파일 시작 부분에서 특정 바이트 수를 읽으려면 다음을 호출하면 됩니다 head.
head -c 1000000m </dev/urandom >file
내 컴퓨터에서 빠른 벤치마크를 수행했지만 dd큰 블록 크기와 head.
처음에 일부 바이트를 건너뛰어야 하는 경우 tail다음으로 파이프하세요 head.
dd if=input of=output count=C bs=B seek=S
<input tail -c +$((S*B+1)) | head -c $((C*B)) >output
진행 상황을 보려면 전화하여 lsof파일 오프셋을 확인하세요. 이는 문자 장치가 아닌 일반 파일(예제의 출력 파일)에서만 작동합니다.
lsof -a -p 1234 -d 1
cat /proc/1234/fdinfo/1
전화해도됩니다pvdd파이프라인의 추가 항목을 희생하여 진행 보고서('s보다 좋음)를 얻으려면 (성능 측면에서 거의 인식할 수 없음)
답변2
경고는 dd단일 읽기에서 블록을 채울 만큼 충분한 데이터를 얻을 수 없을 때 발생합니다. 이는 불규칙하거나 느린 데이터 소스 또는 요청한 블록 크기보다 작은 단위로 데이터를 쓰는 소스에서 발생합니다.
데이터 무결성에는 문제가 없지만 dd부분 읽기가 여전히 읽기 블록으로 간주된다는 문제가 있습니다.
이 옵션을 사용하지 않는 경우 count경고는 거의 중요하지 않으며 단지 성능 고려 사항일 뿐입니다. 하지만 을 사용하면 count요청한 양의 데이터를 얻을 수 없습니다. 부분 읽기로 인해 끝 부분 of보다 작아집니다 .count*bs
따라서 을 사용할 때는 기술적으로 항상 함께 count사용해야 합니다 .iflag=fullblock
부분 블록의 수 +x여야 합니다.
답변3
< /dev/urandom \
dd ibs=4k obs=64k |
dd bs=64k count=16000000 >file
^그렇게 하면 됩니다. 여기에 있는 잘못된 정보는 명백히 거짓입니다. dd의 버퍼는 다음과 같습니다.명백한그래서 입력을 버퍼링하기 위해세다명시적으로 버퍼링해야 하는 발생. 그게 전부입니다. 헛소리를 사지 마십시오.