Le problème avec le seek=<big number> L'astuce est que le système de fichiers est (généralement) intelligent :si une partie d'un fichier n'a jamais été écrite (et est donc entièrement composée de zéros), il ne prend pas la peine de lui allouer de l'espace - donc, comme vous l'avez vu, vous peut avoir un fichier de 10 Go qui n'occupe pas d'espace (c'est ce qu'on appelle un "fichier sparse" et peut être très utile dans certains cas, par exemple certaines implémentations de base de données).
Vous pouvez forcer l'allocation de l'espace avec (par exemple) :
dd if=/dev/zero of=filename bs=$((1024*1024)) count=$((10*1024))
ce qui prendra beaucoup plus de temps, mais remplira en fait le disque. Je recommande de rendre la taille de bloc bien supérieure à un, car cela déterminera le nombre d'appels système au dd processus fait - plus la taille de bloc est petite, plus il y a d'appels système, et donc plus il s'exécutera lentement. (Bien qu'au-delà de 1 Mo environ, cela ne fera probablement pas beaucoup de différence et pourrait même ralentir les choses...)
Comme autre option, vous pouvez utiliser le oui avec une seule chaîne et c'est environ 10 fois plus rapide que d'exécuter dd if=/dev/urandom of=largefile. Comme ça
yes abcdefghijklmnopqrstuvwxyz0123456789 > largefile
Vous avez créé ce que l'on appelle un "fichier sparse" - un fichier qui, parce que la majeure partie est vide (c'est-à-dire qu'il est lu comme \0), ne prend pas d'espace sur le disque en plus de ce qui est réellement écrit (1B, après 10GB de l'écart).
Je ne crois pas que vous puissiez créer des fichiers volumineux, prenant de l'espace disque réel en un instant - prendre de l'espace physique signifie que le système de fichiers doit allouer des blocs de disque à votre fichier.
Je pense que vous êtes coincé avec l'ancien "dd if=/dev/zero of=filename bs=100M count=100" qui est limité par la vitesse d'écriture séquentielle de votre lecteur.