human
Je voulais produire un fichier aléatoire de 1 Go, donc j'ai utilisé la commande suivante.
```dd if=/dev/urandom of=output bs=1G count=1
```
Mais à chaque fois que je lance cette commande, j'obtiens un fichier de 32 Mo :
```$ dd if=/dev/urandom of=output bs=1G count=1
0+1 enregistrements lus
0+1 enregistrements écrits
33554431 octets (34 Mo, 32 MiB) copiés, 0,288321 s, 116 Mo/s
```
Qu'est-ce qui ne va pas
gpt
```bs```, la taille du tampon, signifie la taille d'un seul appel read() effectué par dd. Par exemple, à la fois ```bs=1M count=1``` et ```bs=1k count=1k``` donneront un fichier de 1 MiB, mais la première version le fera en une seule étape, tandis que la seconde le fera en 1024 petits morceaux.

Les fichiers réguliers peuvent être lus avec presque n'importe quelle taille de tampon (tant que ce tampon tient en mémoire), mais les périphériques et les fichiers "virtuels" fonctionnent souvent très près des appels individuels et ont une certaine restriction arbitraire sur la quantité de données qu'ils produiront par appel read().

Pour ```/dev/urandom```, cette limite est définie dans urandom_read() dans 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));
    ...
}
```
Cela signifie que chaque fois que la fonction est appelée, elle limitera la taille demandée à 33554431 octets.
Par défaut, contrairement à la plupart des autres outils, dd ne réessaiera pas après avoir reçu moins de données que demandé - vous obtenez les 32 MiB et c'est tout. (Pour le faire réessayer automatiquement, comme dans la réponse de Kamil, vous devrez spécifier ```iflag=fullblock```.)

Notez également que "la taille d'une seule lecture()" signifie que tout le tampon doit tenir en mémoire en une seule fois, donc des tailles de bloc massives correspondent également à une utilisation massive de la mémoire par dd.

Et tout cela est inutile car vous ne gagnerez généralement pas de performances en dépassant les blocs de ~16-32 MiB - les appels système ne sont pas la partie lente ici, le générateur de nombres aléatoires l'est.

Donc pour simplifier, utilisez simplement ```head -c 1G /dev/urandom > output```.