dd está produzindo um arquivo aleatório de 32 MB em vez de 1 GB

Como eu queria produzir um arquivo aleatório de 1 GB, usei o seguinte comando.

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

Mas, em vez disso, sempre que inicio este comando, recebo um arquivo de 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

O que está errado?

EDITAR:

Graças a ótimas respostas neste tópico, eu vim com uma solução com 32 pedaços de 32 MB de tamanho, o que perfaz 1 GB:

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

Outra solução foi fornecida: lê 1 GB diretamente na memória e depois grava no disco. Esta solução consome muita memória, portanto não é preferida:

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

bs, o tamanho do buffer, significa o tamanho de uma única chamada read () feita por dd.

(Por exemplo, ambos bs=1M count=1e bs=1k count=1kresultará em um arquivo 1 MiB, mas a primeira versão o fará em uma única etapa, enquanto a segunda fará em 1024 pequenos pedaços.)

Os arquivos regulares podem ser lidos em praticamente qualquer tamanho de buffer (desde que esse buffer caiba na RAM), mas os dispositivos e arquivos "virtuais" geralmente trabalham muito perto das chamadas individuais e têm alguma restrição arbitrária da quantidade de dados que eles produzirão por chamada read ().

Para /dev/urandom, este limite é definido em urandom_read () em drivers / char / random.c :

#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));
    ...
}

Isso significa que toda vez que a função for chamada, ela limitará o tamanho solicitado a 33554431 bytes.

Por padrão, diferentemente da maioria das outras ferramentas, o dd não tentará novamente depois de receber menos dados do que o solicitado - você obtém o 32 MiB e é isso. (Para fazê-lo tentar novamente automaticamente, como na resposta de Kamil, você precisará especificar iflag=fullblock.)

Observe também que "o tamanho de uma única leitura ()" significa que todo o buffer deve caber na memória de uma só vez; portanto, tamanhos enormes de blocos também correspondem ao uso massivo de memória por dd .

E é tudo inútil, porque você geralmente não obtém desempenho acima de 16 a 32 blocos MiB - os syscalls não são a parte mais lenta aqui, o gerador de números aleatórios é.

Portanto, para simplificar, basta usar head -c 1G /dev/urandom > output.

ddpode ler menos que ibs(nota: bsespecifica ambos ibse obs), a menos que iflag=fullblockseja especificado. 0+1 records inindica que os 0blocos completos e 1parciais foram lidos. No entanto, qualquer bloqueio total ou parcial aumenta o contador.

Eu não sei o mecanismo exato que faz ddler um bloco que é menor do que 1Gneste caso particular. Eu acho que qualquer bloco é lido na memória antes de ser gravado, portanto, o gerenciamento de memória pode interferir (mas isso é apenas um palpite). Editar: esta resposta simultânea explica o mecanismo que torna a ddleitura de um bloco menor do que 1Gnesse caso específico.

Enfim, eu não recomendo tão grande bs. Eu usaria bs=1M count=1024. O mais importante é: sem iflag=fullblock nenhuma tentativa de leitura, a leitura pode ser menor que ibs(a menos que ibs=1eu ache que isso é bastante ineficiente).

Portanto, se você precisar ler uma quantidade exata de dados, use iflag=fullblock. Nota iflagnão é requerida pelo POSIX, ddtalvez você não a suporte. De acordo com esta resposta, ibs=1 provavelmente é a única maneira POSIX de ler um número exato de bytes. Obviamente, se você alterar ibs, será necessário recalcular o count. No seu caso, diminuir ibspara 32Mou menos provavelmente resolverá o problema, mesmo sem ele iflag=fullblock.

No meu Kubuntu, eu corrigia seu comando assim:

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