윈도우에서는 fsutil 명령어를 이용하여 원하는 용량의 더미 파일을 만들 수 있었습니다. 윈도우에서 대용량 Dummy 파일을 생성하는 방법을 얼마 전에 포스팅하였으니, 블로그 검색창을 이용하여 찾아보시기 바랍니다.

리눅스에서도 테스트 목적으로 더미 파일을 만들 수 있을 것 같아서 구글링해 봤는데, 방법이 여러 가지가 있더군요. 대용량으로 갈수록 파일 생성 속도가 중요할 것이기 때문에 각 방법들마다 특징이 어떤지 좀 더 검색해 봤습니다.

 

 

 

어떤 웹문서들로부터 정보를 얻었나

https://info-lab.tistory.com/302

http://blog.dry8r3ad.com/130

 

https://zetawiki.com/wiki/리눅스_대용량_파일_생성

https://stackoverflow.com/questions/257844/quickly-create-a-large-file-on-a-linux-system

 

첫번째 글, 두번째 글을 통해 동원할 수 있는 명령어들의 종류를 알게 됐습니다.(truncate, fallocate, head, dd)

세번째 글에는 명령어에 넣을 수 있는 옵션들의 기능을 직관적으로 파악할 수 있도록 정리되어 있어서 좋았고,

네번째 글에는 각 명령어들의 장점/한계점을 대략적으로 알 수 있었습니다.

 

최종적으로 선택한 명령어는?

네번째 글이 힌트가 많이 되었습니다. 각 명령어들이 본래 어떤 기능을 하는 녀석인지 생각해보면 장점과 한계점이 자연스럽게 드러날 것 같았습니다.

 

예를 들어, truncate 명령어가 굉장히 빠른 이유는 해당 명령어가 sparse file을 생성하는 식으로 작동하기 때문인데, 위키백과(영어)에서 sparse file 용어의 뜻을 찾아보면 "블록을 구성하는 실제의 "빈" 공간 대신 빈 블록을 나타내는 간략한 정보(메타데이터) 작성하여 기록함으로써 저장 공간을 덜 소모하는 식으로 sparse file이 기능한다"고 나와 있습니다. 전체 블록 크기는 블록에 "(비어 있지 않은) 실제" 데이터가 포함된 경우에만 실제 크기로 미디어에 기록된다 하고요.

=> 그러니까 truncate 명령어로 생성한 더미 파일은 깡통일 가능성이 높습니다. 그래서 탈락. 가상머신(VM) 동적 디스크 설정 용으로는 좋을 것 같고, 저처럼 전송 테스트용으로 활용할 것이면 부적합해 보였습니다.

 

▲ 도움말에도 나와 있습니다. 파일이 지정한 크기보다 작으면 확장 부분을 0바이트로 읽습니다.ㄷㄷ

 

fallocate 명령어의 경우, 우분투 매뉴얼 페이지 설명에 따르면 이 명령어가 빠른 이유는 디스크 입/출력을 실제로 하지 않으면서 블록 할당만을 해버리기 때문이라고 합니다. VM 디스크 할당할 때 사용하면 좋은 선택지라고 하는데, 실제로 속도가 빠르다면 이 명령어로 정착할 것 같습니다.

 

▼ fallocate 명령어는 -l 옵션과 함께 쓰면 될 것 같습니다.

 

head 명령어의 -c 옵션을 이용해서 /dev/urandom 같은 0바이트 용량의 파일을 반복 출력하여 원하는 용량만큼 묶는 방법. 기상 천외하죠? 접수.ㅋ

 

dd 명령어. 파일을 복사하고, 변환하고, 포매팅합니다. 가장 정석적인 방법인 것 같습니다. 접수.

 

소제목을 "최종 선택한 명령어는?"이라고 지었는데, fallocate, head, dd 명령어들 중에서 우열을 가리기가 힘드네요. 직접 테스트 후 결정을 내려야겠습니다.

 

테스트(time 명령어 이용)

테스트 파일의 용량을 10GB로 정할 겁니다.

노트북 NVME SSD의 쓰기캐시 구간이 5GB에서 끝나기 때문에 아쉽긴 한데, 캐시 구간이 끝나도 충분히 빠른 쓰기 속도가 나오므로 해볼만 하다고 생각합니다.

 

ZHITAI PC005 NVMe 게임용 SSD 512. 중국 반도체 굴기를 느껴요!

 

모든 명령어 앞에 time 명령어를 붙이겠습니다. 실제로 더미 파일을 생성할 때에는 time을 빼고 이용하면 되겠습니다. 각 명령어의 옵션의 역할은 두번째 소제목에서 확인 가능합니다.

 

▼ time fallocate -l 10G fallocate_test.txt

(10GB의 용량을 fallocate_test.txt 파일로 생성하라.)

 

▼ time head -c 10G /dev/urandom > head_test.txt

(/dev/urandom 파일의 첫부분 10G 만큼을 출력하여 head_test.txt 파일에 기록하라.)

 

▼ time dd if=/dev/zero of=dd_test.txt bs=1G count=10

(/dev/zero 파일을 읽어들여 dd_text.txt 파일에 기록하라. 한번에 최대 1GB만큼 읽기/쓰기하여 10번 반복하라 => 1x10=10GB)

 

결론

표로 정리하겠습니다.

 

명령어 총 시간(total) CPU 점유율
fallocate 0.009 56%
dd 10.145 70%
head 4:02.76 99%

 

fallocate > dd > head 순으로 좋은 것 같습니다. head는 10GB 더미 파일을 생성하는 데에 4분이 넘게 걸리고 CPU 점유율도 99%에 달했습니다.

dd 명령어는 읽어들이는 파일이 안 좋으면 10GB 파일이 완성되기 전에 중단되거나, bs 옵션을 크게 설정하면 못 버티고 중단되는 증상이 있었습니다. 이 경우 출력된 더미 파일의 용량이 목표 용량(10GB)에 못 미치는 문제가 생기더군요. => 전반적으로 제어하기 까다로웠습니다. bs 옵션을 4096킬로바이트(4096KB=4M)로 하고 count 숫자를 증감하는 식으로 원하는 용량을 구성하면 안정적일 것 같습니다.

 

저는 fallocate를 주력으로 쓰고, dd는 보조로 쓰게 될 것 같습니다.

예를 들어 fallocate 명령어는 NTFS 파티션에서 실행되지 않는데, dd는 실행이 됩니다. 그래서 dd를 요긴하게 쓰게 될 것 같습니다.

반응형