dd 正在生成一个 32 MB 的随机文件而不是 1 GB

Question

我想生成一个 1 GB 的随机文件，所以我使用了以下命令。

dd if=/dev/urandom of=output bs=1G count=1

但是每次我启动这个命令时，我都会得到一个 32 MB 的文件：

<11:58:40>$ dd if=/dev/urandom of=output bs=1G count=1
0+1 records in
0+1 records out
33554431 bytes (34 MB, 32 MiB) copied, 0,288321 s, 116 MB/s

怎么了？

编辑：

感谢本主题中的出色答案，我提供了读取 32 个 32 MB 大块的解决方案，这使得 1GB：

dd if=/dev/urandom of=output bs=32M count=32

给出了其他解决方案，将 1 GB 直接读取到内存，然后写入磁盘。此解决方案需要大量内存，因此不推荐使用：

dd if=/dev/urandom of=output bs=1G count=1 iflag=fullblock

Answer 1

bs，缓冲区大小，表示由 dd 完成的单个read()调用的大小。

（例如，bs=1M count=1和bs=1k count=1k都会产生一个 1 MiB 的文件，但第一个版本将在一个步骤中完成，而第二个将在 1024 个小块中完成。）

常规文件几乎可以在任何缓冲区大小下读取（只要该缓冲区适合 RAM），但设备和“虚拟”文件通常与单个调用非常接近，并且对它们每次生成的数据量有一些任意限制读取（）调用。

对于/dev/urandom，此限制在drivers/char/random.c中的urandom_read()中定义：

#define ENTROPY_SHIFT 3

static ssize_t
urandom_read(struct file *file, char __user *buf, size_t nbytes, loff_t *ppos)
{
    nbytes = min_t(size_t, nbytes, INT_MAX >> (ENTROPY_SHIFT + 3));
    ...
}

这意味着每次调用该函数时，它都会将请求的大小限制为 33554431 字节。

默认情况下，与大多数其他工具不同，dd在接收到的数据少于请求的数据后不会重试——您将获得 32 MiB，仅此而已。（要使其自动重试，如 Kamil 的回答，您需要指定iflag=fullblock.）

另请注意，“单个 read() 的大小”意味着整个缓冲区必须一次适合内存，因此大量块大小也对应于dd 的大量内存使用。

而且这一切都是毫无意义的，因为当超过 ~16–32 MiB 块时通常不会获得任何性能 - 系统调用不是这里的慢部分，随机数生成器才是。

因此，为简单起见，只需使用head -c 1G /dev/urandom > output.

Answer 2

dd可以读取小于ibs（注意：bs指定两者ibs和obs），除非iflag=fullblock指定。0+1 records in表示读取了0完整块和1部分块。然而，任何完整或部分块都会增加计数器。

我不知道产生的确切机制 ddread 块小于1G这种特殊情况。我猜任何块在写入之前都会被读取到内存中，因此内存管理可能会干扰（但这只是一个猜测）。编辑：此并发答案解释了使dd读取块小1G于此特定情况下的机制。

反正我不推荐这么大 bs. 我会使用bs=1M count=1024. 最重要的是：没有iflag=fullblock 任何读取尝试可能读取不到ibs（除非ibs=1，我认为，这虽然效率很低）。

因此，如果您需要读取一些确切数量的数据，请使用iflag=fullblock. 注意iflagPOSIX 不需要，您dd可能不支持它。根据这个答案 ibs=1可能是读取确切字节数的唯一 POSIX 方法。当然，如果您更改，ibs则需要重新计算count. 在您的情况下，降低ibs到32M或更少可能会解决问题，即使没有iflag=fullblock.

在我的 Kubuntu 中，我会像这样修复你的命令：

dd if=/dev/urandom of=output bs=1M count=1024 iflag=fullblock