dd est une bonne solution, mais elle est lente dans ce but. Sous Linux, nous avons fallocate .

par exemple:

fallocate -l 10G gentoo_root.img

C'est une question courante, surtout dans l'environnement actuel des environnements virtuels. Malheureusement, la réponse n'est pas aussi simple qu'on pourrait le supposer.

dd est le premier choix évident, mais dd est essentiellement une copie et cela vous oblige à écrire chaque bloc de données (donc, initialiser le contenu du fichier)... Et cette initialisation est ce qui prend tellement de temps D'entrée/sortie. (Vous voulez que ce soit encore plus long? Utiliser / dev / random à la place de / dev / zero ! Alors vous utiliserez CPU aussi bien que le temps d'entrée/sortie!) En fin de compte, dd est un mauvais choix (bien que ce soit essentiellement la valeur par défaut utilisée par les interfaces graphiques vm "create"). Par exemple:

dd if=/dev/zero of=./gentoo_root.img bs=4k iflag=fullblock,count_bytes count=10G

tronqué est un autre choix -- et est probablement le plus rapide... Mais c'est parce qu'il crée un fichier fragmenté". Essentiellement, un fichier clairsemé est une section de disque qui a beaucoup des mêmes données, et le système de fichiers sous-jacent "trompe" par pas vraiment stocker toutes les données, mais juste "prétendre" que tout est là. Ainsi, lorsque vous utilisez truncate pour créer un lecteur de 20 Go pour votre VM, le système de fichiers n'alloue pas réellement 20 Go, mais il trompe et dit qu'il y a 20 Go de zéros là-bas, même si aussi peu qu'une piste sur le disque peut effectivement (vraiment) être utilisée. Par exemple:

 truncate -s 10G gentoo_root.img

fallocate est le final -- et meilleur -- choix pour une utilisation avec l'allocation de disque VM, parce qu'il essentiellement "réserve" (ou "alloue" tout l'espace que vous recherchez, mais il ne prend pas la peine d'écrire quoi que ce soit. Donc, quand vous utilisez fallocate pour créer un espace de disque virtuel de 20 Go, vous obtenez vraiment un fichier de 20 Go (pas un "fichier clairsemé", et vous n'aurez pas pris la peine de lui écrire quoi que ce soit -- ce qui signifie que pratiquement tout pourrait être là-dedans -- un peu comme un disque tout neuf!) Par exemple:

fallocate -l 10G gentoo_root.img

Linux & tous les systèmes de fichiers

xfs_mkfile 10240m 10Gigfile

Linux & et certains systèmes de fichiers (ext4, xfs, btrfs et ocfs2)

fallocate -l 10G 10Gigfile

OS X, Solaris, SunOS et probablement D'autres UNIXes

mkfile 10240m 10Gigfile

HP-UX

prealloc 10Gigfile 10737418240

explication

Essayer mkfile <size> myfile comme une alternative de dd . Avec l'option -n la taille est notée, mais les blocs de disques ne sont pas alloués tant que les données ne leur sont pas écrites. Sans l'option -n , l'espace est rempli à zéro, ce qui signifie écrire sur le disque, ce qui signifie prendre du temps.

mkfile est dérivé de SunOS et n'est pas disponible partout. La plupart des systèmes Linux ont xfs_mkfile qui fonctionne exactement de la même façon, et pas seulement sur les systèmes de fichiers XFS malgré le nom. Il est inclus dans xfsprogs (Pour Debian/Ubuntu) ou des paquets nommés similaires.

la plupart des systèmes Linux ont aussi fallocate , qui ne fonctionne que sur certains systèmes de fichiers (tels que btrfs, ext4, ocfs2, et xfs), mais qui est le plus rapide, car il attribue tout l'espace de fichier (crée des fichiers non holey) mais n'en initialise aucun.

truncate -s 10M output.file

va créer un fichier 10 M instantanément (M signifie 1024*1024 octets, MB signifie 1000*1000 - même avec K, KB, G, GB...)

EDIT: comme beaucoup l'ont souligné, cela ne va pas affecter physiquement le fichier sur votre appareil. Avec cela, vous pouvez réellement créer un grand fichier arbitraire, indépendamment de l'espace disponible sur le périphérique

ainsi, en faisant cela, vous reporterez l'attribution physique jusqu'à ce que le fichier soit accédé. Si vous mettez ce fichier en mémoire, vous n'aurez peut-être pas la performance attendue.

mais c'est encore une commande utile pour savoir

Où chercher est la taille du fichier en octets - 1.

dd if=/dev/zero of=filename bs=1 count=1 seek=1048575

exemples où seek est la taille du fichier que vous voulez en octets

#kilobytes
dd if=/dev/zero of=filename bs=1 count=0 seek=200K

#megabytes
dd if=/dev/zero of=filename bs=1 count=0 seek=200M

#gigabytes
dd if=/dev/zero of=filename bs=1 count=0 seek=200G

#terabytes
dd if=/dev/zero of=filename bs=1 count=0 seek=200T

du manpage dd:

blocs et octets peuvent être suivis des suffixes multiplicatifs suivants: c=1, w=2, b=512, kB=1000, K= 1024, MB = 1000*1000, M=1024*1024, GB =1000*1000*1000, G=1024*1024*1024, et ainsi de suite pour T, P, E, Z, Y.

Je ne sais pas grand chose sur Linux, mais voici le Code C que j'ai écrit pour simuler d'énormes fichiers sur DC Share il y a de nombreuses années.

#include < stdio.h >
#include < stdlib.h >

int main() {
    int i;
    FILE *fp;

    fp=fopen("bigfakefile.txt","w");

    for(i=0;i<(1024*1024);i++) {
        fseek(fp,(1024*1024),SEEK_CUR);
        fprintf(fp,"C");
    }
}

pour créer un fichier de 1 Go:

dd if=/dev/zero of=filename bs=1G count=1

vous pouvez aussi utiliser la commande" Oui". La syntaxe est assez simple:

#yes >> myfile

Appuyez sur "Ctrl + C" pour arrêter cela, sinon il va manger tout votre espace disponible.

Pour nettoyer ce fichier, exécutez:

#>myfile

nettoiera ce fichier.

Je ne pense pas que tu iras beaucoup plus vite que dd. Le goulot d'étranglement est le disque; l'écriture des centaines de GO de données, il est va prendre beaucoup de temps, peu importe comment vous le faites.

Mais voici une possibilité qui pourrait fonctionner pour votre application. Si vous ne vous souciez pas du contenu du fichier, Pourquoi ne pas créer un fichier "virtuel" dont le contenu est la sortie dynamique d'un programme? Au lieu d'ouvrir () le fichier, utilisez popen () pour ouvrir une pipe à un programme externe. Le programme externe génère des données chaque fois que c'est nécessaire. Une fois que la pipe est ouverte, elle agit comme un fichier régulier en ce que le programme qui a ouvert la pipe peut fseek(), rewind(), etc. Vous devrez utiliser pclose() au lieu de close () lorsque vous aurez terminé avec la pipe.

si votre application a besoin que le fichier soit d'une certaine taille, ce sera au programme externe de garder une trace de l'endroit où dans le" fichier "il est et d'envoyer un eof lorsque la" fin " a été atteinte.

une approche: si vous pouvez garantir que les applications non liées n'utiliseront pas les fichiers d'une manière conflictuelle, créez simplement un pool de fichiers de tailles variables dans un répertoire spécifique, puis créez des liens vers eux si nécessaire.

par exemple, avoir un pool de fichiers appelés:

• / home / bigfiles/512M-A
• / home/bigfiles/512M-B
• / home / bigfiles/1024M-A
• / accueil/bigfiles/1024M-b

ensuite, si vous avez une application qui nécessite un fichier 1G appelé /home/oracle/logfile, exécutez un" ln /home/bigfiles/1024M-A /home/oracle/logfile ".

Si c'est sur un autre système de fichiers, vous devrez utiliser un lien symbolique.

les fichiers A/B / etc peuvent être utilisés pour s'assurer qu'il n'y a pas d'utilisation conflictuelle entre des demandes indépendantes.

l'opération link est aussi rapide que possible.

le MKFILE GPL est juste un enveloppeur de script (ba)sh autour de dd; le MKFILE de BSD mémorise juste un tampon avec non-zéro et l'écrit à plusieurs reprises. Je ne voudrais pas que l'ancien à effectuer dd. Ce dernier risque d'écarter dd if= / dev / zero légèrement puisqu'il omet les lectures, mais tout ce qui fait significativement mieux ne fait probablement que créer un fichier clairsemé.

Absent un appel système qui attribue réellement l'espace pour un fichier sans écrire de données (et Linux et BSD manquent ceci, probablement Solaris aussi) vous pourriez obtenir une petite amélioration dans la performance en utilisant ftrunc(2)/truncate(1) pour étendre le fichier à la taille désirée, mmap le fichier dans la mémoire, puis écrire des données non-zéro aux premiers octets de chaque bloc de disque (utilisez fgetconf pour trouver la taille du bloc de disque).

C'est le plus rapide que je pouvais faire (qui est pas rapide) avec les contraintes suivantes:

• le but du Grand fichier est de remplir un disque, donc ne peut pas être compressible.
• utilisant le système de fichiers ext3. (fallocate non disponible)

C'est l'essentiel...

// include stdlib.h, stdio.h, and stdint.h
int32_t buf[256]; // Block size.
for (int i = 0; i < 256; ++i)
{
    buf[i] = rand(); // random to be non-compressible.
}
FILE* file = fopen("/file/on/your/system", "wb");
int blocksToWrite = 1024 * 1024; // 1 GB
for (int i = 0; i < blocksToWrite; ++i)
{
   fwrite(buf, sizeof(int32_t), 256, file);
}

`

Dans notre cas, c'est pour un système linux embarqué et cela fonctionne assez bien, mais préférez quelque chose de plus rapide.

POUR INFORMATION, la commande "dd if=/dev / urandom of=outputfile bs = 1024 count = XX" était si lente qu'elle était inutilisable.

Shameless plug: OTFFS fournit un système de fichiers offrant arbitrairement grand (enfin, presque. Exaoctets est la limite actuelle) des fichiers de contenu généré. C'est Linux-seulement, c simple, et au début alpha.

voir https://github.com/s5k6/otffs .