최근에 logrotate를 가지고 놀고 싶어서 테스트 파일을 만들었습니다. 임의 크기의 파일을 생성하는 솔루션을 찾고 있습니다. 나는 이것이 내 해결책이라는 것을 알았습니다.
dd if=/dev/zero of=/path bs=1M count=30 status=progress
나는 또한 이것을 발견했습니다:
dd if=/dev/urandom of=/path bs=1M count=30 status=progress
첫 번째 예에서는 0이 포함된 파일을 만들고, 두 번째 예에서는 임의의 텍스트가 포함된 파일을 만듭니다. 두 파일의 크기는 모두 30M로 동일합니다.
0보다 임의의 텍스트로 이 파일을 만드는 데 시간이 더 오래 걸리는 이유를 설명할 수 있는 사람이 있습니까? 데이터 크기가 똑같기 때문에..
미리 감사드립니다 :)
답변1
출력에서 볼 수 있듯이 두 방법 모두 매우 빠릅니다. 그러나 데이터 소스 간에는 분명한 차이가 있습니다.
/dev/zero더미 파일이므로 제로 스트림을 생성합니다. 이는 매우 간단한 작업입니다./dev/urandom실제로 커널의 엔트로피 풀에 액세스하여 난수를 생성하므로 단순히 동일한 고정 값을 생성하는 것보다 빠릅니다/dev/zero.
/dev/urandom이것이 에서 읽는 것이 에서 읽는 것만큼 빠르지 않은 이유입니다 /dev/zero. 관심이 있으시면,에 관한 Wikipedia 기사/dev/random추가 독서를 위한 출발점으로 사용할 수 있습니다.
답변2
디스크에 있는 파일은 입력 장치에서 출력된 내용을 바이트 단위로 복사한 것일 뿐이라고 가정합니다. 반드시 그런 것은 아닙니다.
데이터 소스(이미 다른 답변에서 다루었음) 외에도 파일 시스템 압축, 중복 제거 및 스파스 파일 생성 가능성과 같은 성능의 또 다른 잠재적인 차이가 있습니다.
데이터를 압축하는 파일 시스템에 0만 있는 파일을 쓰는 경우, 그러한 파일 시스템이 해야 할 일은 모든 0의 "크기"를 계속 업데이트하는 것뿐입니다. 유일한 내용이 0이라는 사실과 디스크에 기록해야 하는 이러한 0의 개수를 제외하고는 정보가 없기 때문에 이 작업은 매우 빠르게 수행될 수 있습니다.
진정한 무작위 데이터는 전혀 압축할 수 없습니다.
파일 시스템은 괜찮습니다"중복 제거" 블록특히 ZFS와 같은 쓰기 시 복사 파일 시스템의 경우 파일이 압축되지 않은 경우에도 마찬가지입니다. 중복 제거를 수행하는 파일 시스템에서는 0으로 구성된 블록을 디스크에 쓴 다음 해당 블록에 대한 참조를 추가하기만 하면 됩니다.
무작위 데이터는 중복 블록을 생성할 가능성이 매우 낮습니다.
파일 시스템은 또한 블록의 내용이 모두 0임을 감지하고스파스 파일- 어디아무것도 없다디스크에 기록해야 합니다.
이 모든 것은 실제로 디스크에 0을 모두 쓰는 것보다 훨씬 빠릅니다.