Réponses:
La méthode de remplissage nul (modifiée ici pour éviter les goulots d'étranglement potentiels de la mémoire ) a pris 17 secondes pour créer un fichier de 10 Go sur un SSD et a causé que l'interface graphique d'Ubuntu ne répondait plus.
$ time sh -c 'dd if=/dev/zero iflag=count_bytes count=10G bs=1M of=large; sync'
10240+0 records in
10240+0 records out
10737418240 bytes (11 GB, 10 GiB) copied, 17.2003 s, 624 MB/s
real 0m17.642s
user 0m0.008s
sys 0m9.404s
$ du -B 1 --apparent-size large
10737418240 large
$ du -B 1 large
10737422336 large
fallocate crée des fichiers volumineux instantanément en manipulant directement l'espace disque alloué au fichier:
$ time sh -c 'fallocate -l 10G large; sync'
real 0m0.038s
user 0m0.000s
sys 0m0.016s
$ du -B 1 --apparent-size large
10737418240 large
$ du -B 1 large
10737422336 large
truncate fonctionne également instantanément et crée des fichiers clairsemés qui n'utilisent pas l'espace disque réel jusqu'à ce que les données soient écrites plus tard:
$ time sh -c 'truncate -s 10G large; sync'
real 0m0.014s
user 0m0.000s
sys 0m0.004s
$ du -B 1 --apparent-size large
10737418240 large
$ du -B 1 large
0 large
Un moyen simple serait d'utiliser la dd
commande pour écrire un fichier plein de zéros.
dd if=/dev/zero of=outputFile bs=2G count=1
Utilisez G dans l'argument taille si vous voulez des gigaoctets d'ordinateur (1024 * 1024 * 1024), ou Go si vous voulez des gigaoctets humains (1000 * 1000 * 1000).
/dev/urandom
dans ce cas (c'est non bloquant, mais il n'est pas garanti d'avoir le même niveau de caractère aléatoire). Dessiner 2 Go à partir de l'un ou l'autre épuisera presque certainement complètement l'entropie de votre système, alors ne faites rien de cryptographique pendant un certain temps après.
ftp://ftp.fsf.hu/testfiles/maketestfiles.sh
ou Seek est la taille du fichier souhaité en octets - 1.
dd if=/dev/zero of=filename.big bs=1 count=1 seek=1048575 # 1 MByte
dd if=/dev/zero of=filename.big bs=1 count=1 seek=10485759 # 10 MByte
dd if=/dev/zero of=filename.big bs=1 count=1 seek=104857599 # 100 MByte
dd if=/dev/zero of=filename.big bs=1 count=1 seek=1073741823 # 1024 MByte
dd if=/dev/zero of=filename.big bs=1 count=1 seek=42949672959 # 40960 MByte
dd ... bs=2G count=1
lit 2 Go en mémoire (en un seulread(2)
appel). Si vous avez une pression sur la mémoire, ce n'est probablement pas la voie à suivre. De plus, des blocs plus petits peuvent être plus rapides si cela signifie moins de pagination.