bs La taille de la mémoire tampon correspond à la taille d'une seule image. lire() appel effectué par le dd.
(Par exemple, les deux bs=1M count=1 y bs=1k count=1k aboutira à un fichier de 1 Mio, mais la première version le fera en une seule étape, tandis que la seconde le fera en 1024 petits morceaux).
Les fichiers ordinaires peuvent être lus à presque n'importe quelle taille de tampon (tant que ce tampon tient dans la RAM), mais les périphériques et les fichiers "virtuels" travaillent souvent très près des appels individuels et ont une restriction arbitraire de la quantité de données qu'ils produiront par appel read().
Para /dev/urandom Cette limite est définie dans urandom_read() en 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 réduit la taille demandée à 33554431 octets.
Par défaut, contrairement à la plupart des autres outils, dd ne réessayera pas après avoir reçu moins de données que demandé - vous obtenez les 32 MiB et c'est tout. (Pour qu'il réessaie automatiquement, comme dans la réponse de Kamil, vous devrez spécifier iflag=fullblock .)
Notez également que "la taille d'un seul read()" signifie que l'ensemble du tampon doit tenir dans la mémoire en une seule fois, de sorte que les tailles de bloc massives correspondent également à une utilisation massive de la mémoire en dd .
Et tout cela est inutile car vous ne gagnerez généralement pas en performance lorsque vous dépasserez les blocs de ~16-32 MiB - les syscalls ne sont pas la partie lente ici, c'est le générateur de nombres aléatoires qui l'est.
Pour simplifier, il suffit donc d'utiliser head -c 1G /dev/urandom > output .
