Quand les paramètres bs et count pour dd sont-ils erronés?

(Par erreur, je veux dire "va casser les choses".)

Supposons que nous soyons sur le point d'utiliser dd. Nous avons choisi un ensemble valide de if, of, et éventuellement seek et skip. Nous avons soigneusement veillé à ce que la commande n'écrive pas au-delà de notre région de sortie prévue.

Comment pouvons-nous maintenant casser subtilement les choses en choisissant une mauvaise combinaison de bs et count? Comment le saurions-nous ?

La raison pour laquelle je demande est qu'il semble y avoir des valeurs préférées magiques qui apparaissent. Pour exemple, dans cette question sur la génération d'un fichier 1G aléatoire, les deux premières réponses utilisent if=/dev/urandom, of=sample.txt, bs=64M, et count=16.

Comment créer un fichier aléatoire de 1 Go sous Linux ?

Bien sûr, ce ne sont pas les seuls paramètres valides, mais les deux réponses ont utilisé ces paramètres, suggérant que ce choix est particulièrement bon et raisonnable. Surtout dans un cas comme celui-ci où il n'y a pas de système de fichiers ou même de disque physique, il n'est pas clair pour moi si un choix de paramètres peut être erroné -- pas seulement inefficace, mais mauvais . Je suppose que dd doit écrire un nombre intégral de blocs à la fois afin que bs augmente de même que l'utilisation de la mémoire et que ces valeurs n'affectent que les performances.

L'exemple n'est qu'un exemple et pas quelque chose qui me concerne spécifiquement, alors allez-y et abordez les cas où ce qui est copié a un système de fichiers.

Utiliser dd est toujours un acte de foi effrayant pour moi.