linux目录怎么自动生成,情景linux--如何快速生成大文件？

情景

在写情景linux--如何解决服务器日志过大导致的磁盘空间不足？(实践篇)时，因为要实际演示，所以需要快速创建一个大文件。其实，在实际工作过程中，有些时候是有这种需求的。今天就将其作为一个话题探讨下。

创建文件有很多种途径，如常见的命令有：touch命令、vi(m)命令、tee命令、>或>>、cp命令，或者它们的组合，等等。如果要创建一个大文件(比如>10GB)，使用上述命令，结合循环语句也不难实现，但效率就差强人意了。

方案

BTW：此处举例统一用100MB的文件。

dd命令

dd命令，可以从标准输入或指定的文件中读取数据，拷贝至新文件。

dd if=/dev/zero of=my_new_file count=102400 bs=1024

102400+0 records in

102400+0 records out

104857600 bytes (105 MB) copied, 0.642327 s, 163 MB/s

参数if为输入文件名，of为输出文件名，bs为单次读取和写入的字节数，count为拷贝的次数，因而总文件大小为bs*count。最后一行括号中的105MB显然是把104857600 bytes按1000的量级换算出来的，因而不是精确值，不必细究。

wc my_new_file

0 0 104857600 my_new_file

od -tc my_new_file

0000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0

*

620000000

由wc的结果可知，生成的文件my_new_file的行数是0(不理解为什么是0的，请参见文章情景linux--wc -l是用来统计文件行数的吗？)，单词数为0，字节数为104857600。

由od命令的结果可知，文件中的内容全部为\0空字符。这是由于我们的输入文件是/dev/zero——一个特殊的文件，提供无限个空字符(NULL、0x00)。

如果希望文件有多行信息，可以将if设置为/dev/urandom——提供不为空字符的随机字节数据流。

dd if=/dev/urandom of=detail_1 count=102400 bs=1024

102400+0 records in

102400+0 records out

104857600 bytes (105 MB) copied, 13.3349 s, 7.9 MB/s

wc detail_1

409483 2323021 104857600 detail_1

od -tc detail_1 | head -n 2

0000000 276 313 R * 274 273 372 N 266 034 346 i K 316 b p

0000020 302 | 314 243 [ 323 x 021 016 ? 016 275 270 266 ; #

fallocate命令

fallocate命令可以为文件预分配物理空间。-l后接空间大小，默认单位为字节。也可后跟k、m、g、t、p、e来指定单位，分别代表KB、MB、GB、TB、PB、EB。

fallocate -l 100m new_file_2

wc new_file_2

0 0 104857600 new_file_2

od -tc new_file_2

0000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0

*

620000000

可见，fallocate命令分配出的内容也是空字符。

truncate命令

truncate命令可以将文件缩减或扩展为指定大小，使用-s参数设置大小。

truncate -s 100M new_file_3

wc new_file_3

0 0 104857600 new_file_3

od -tc new_file_3

0000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0

*

620000000

可见，truncate命令分配出的内容也是空字符。

性能比较

既然我们希望快速得到大文件，那性能就是一个关键因素了。

BTW：此处举例统一用20GB的文件。

dd命令的性能

sync ; time (dd if=/dev/zero of=20G_dd bs=2048 count=10485760 ; sync)

10485760+0 records in

10485760+0 records out

21474836480 bytes (21 GB) copied, 280.953 s, 76.4 MB/s

( dd if=/dev/zero of=20G_dd bs=2048 count=10485760; sync; ) 1.11s user 28.16s system 9% cpu 4:57.19 total

dd命令所产生的文件大小是由count和bs的乘积，所以我总觉得dd命令的执行时间应该是关于count或bs的函数，究竟是不是这样的呢？于是，调整参数：

sync ; time (dd if=/dev/zero of=20G_dd_2 bs=10485760 count=2048 ; sync)

2048+0 records in

2048+0 records out

21474836480 bytes (21 GB) copied, 280.843 s, 76.5 MB/s

( dd if=/dev/zero of=20G_dd_2 bs=10485760 count=2048; sync; ) 0.01s user 19.89s system 6% cpu 4:57.08 total

sync ; time (dd if=/dev/zero of=20G_dd_3 bs=1048576 count=20480 ; sync)

20480+0 records in

20480+0 records out

21474836480 bytes (21 GB) copied, 280.614 s, 76.5 MB/s

( dd if=/dev/zero of=20G_dd_3 bs=1048576 count=20480; sync; ) 0.03s user 18.21s system 6% cpu 4:49.55 total

由上数据，无论是bs=2048 count=10485760,bs=10485760 count=2048还是bs=1048576 count=20480，时间差异都很小，对应地，拷贝速度也基本上是定值。

这是因为，dd命令的原理是从一个文件中复制数据并拷贝到另一个文件中，所以与设置不同的参数相比，dd的性能更依赖于硬盘的读取和写入速度，这也是为什么平均速度只有约76 MB/s的原因。

其实，dd命令自身提供了可以更快的参数seek=BLOCKS：在输出文件的开始处跳过BLOCKS个块后再开始复制。

sync ; time (dd if=/dev/zero of=20G_dd_4 bs=1 count=0 seek=20G; sync)

0+0 records in

0+0 records out

0 bytes (0 B) copied, 6.971e-06 s, 0.0 kB/s

( dd if=/dev/zero of=20G_dd_4 bs=1 count=0 seek=20G; sync; ) 0.00s user 0.00s system 0% cpu 0.227 total

因为跳过的部分并没有进行硬盘读写，所以执行时间极大地缩短。

od -tc 20G_dd_4

0000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0

*

240000000000

而文件开头跳过的部分，也都是\0字符。

fallocate命令的性能

sync ; time (fallocate -l 20G 20G_fallocate ; sync)

( fallocate -l 20G 20G_fallocate; sync; ) 0.00s user 0.02s system 0% cpu 7.775 total

truncate命令

sync ; time (truncate -s 20G 20G_truncate ; sync)

( truncate -s 20G 20G_truncate; sync; ) 0.00s user 0.00s system 1% cpu 0.257 total

总结

从上面命令的执行结果，可以大致得出这样的结论：

不使用seek参数的dd命令在生成20G的文件时，速度并不算太快，瓶颈是硬盘读写速度。

使用seek参数的dd命令的执行速度则非常快，时间小于1s。

truncate命令的执行速度也非常快，时间小于1s。

fallocate命令的执行速度略慢，但创建20G的文件时间不到10s，也并不算慢。

PS：上述命令得出的速度数据跟操作系统的软硬件配置有关。

参考链接

相关命令

dd

truncate

fallocate

od

sync

time