Créer rapidement un fichier volumineux sur un système Linux

Question

Comment puis-je rapidement créer un gros fichier sur un Linux ( Red Hat Linux ) ?

dd fera l'affaire, mais la lecture de /dev/zero et l'écriture sur le disque peut prendre beaucoup de temps lorsque vous avez besoin d'un fichier de plusieurs centaines de Go pour des tests... Si vous devez faire cela à plusieurs reprises, le temps s'accumule vraiment.

Je ne me soucie pas du contenu du fichier, je veux juste qu'il soit créé rapidement. Comment cela peut-il être fait ?

L'utilisation d'un fichier épars ne fonctionnera pas dans ce cas. J'ai besoin qu'un espace disque soit alloué au fichier.

Answer 1

dd des autres réponses est une bonne solution, mais elle est lente pour cet objectif. Sous Linux (et autres systèmes POSIX), nous avons fallocate qui utilise l'espace désiré sans avoir à y écrire, fonctionne avec la plupart des systèmes de fichiers modernes sur disque, très rapide :

Par exemple :

fallocate -l 10G gentoo_root.img

Answer 2

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

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 tant de temps d'E/S. (Vous voulez que cela prenne encore plus de temps ? Utilisez /dev/random au lieu de /dev/zero ! Alors vous utiliserez le CPU ainsi que le temps d'E/S !) En fin de compte, cependant, dd est un mauvais choix (bien qu'il s'agisse essentiellement du choix par défaut utilisé 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'elle crée un "fichier clairsemé". Essentiellement, un fichier clairsemé est une section du disque qui contient beaucoup de données identiques, et le système de fichiers sous-jacent "triche" en ne stockant pas réellement toutes les données, mais en "prétendant" qu'elles sont toutes là. Ainsi, lorsque vous utilisez truncate pour créer un disque de 20 Go pour votre VM, le système de fichiers n'alloue pas réellement 20 Go, mais il triche et dit qu'il y a 20 Go de zéros, même si une seule piste du disque peut être réellement (vraiment) utilisée. Par exemple :

 truncate -s 10G gentoo_root.img

fallocate est le finale -- et meilleur -- choix pour une utilisation avec l'allocation de disque VM, parce qu'il "réserve" (ou "alloue") essentiellement tout l'espace que vous recherchez, mais il ne prend pas la peine d'écrire quoi que ce soit. Ainsi, lorsque vous utilisez fallocate pour créer un espace de disque virtuel de 20 Go, vous obtenez réellement un fichier de 20 Go (pas un "fichier clairsemé", et vous n'aurez pas pris la peine d'y écrire quoi que ce soit -- ce qui signifie que pratiquement n'importe quoi pourrait s'y trouver -- un peu comme un tout nouveau disque !) Par exemple :

fallocate -l 10G gentoo_root.img

Answer 3

Linux et 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 UNIX.

mkfile 10240m 10Gigfile

HP-UX

prealloc 10Gigfile 10737418240

Explication

Essayez mkfile <size> monfichier au lieu de dd . Avec le -n la taille est notée, mais les blocs de disque ne sont pas alloués tant que des données n'y sont pas écrites. Sans l'option -n l'espace est rempli à zéro, ce qui signifie écrire sur le disque, ce qui prend 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 manière, et pas seulement sur les systèmes de fichiers XFS malgré son nom. Il est inclus dans xfsprogs (pour Debian/Ubuntu) ou des paquets de nom similaire.

La plupart des systèmes Linux ont également 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 alloue tout l'espace de fichiers (crée des fichiers nonholey) mais n'en initialise aucun.

Answer 4

truncate -s 10M output.file

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

EDITAR: comme beaucoup l'ont souligné, cela n'allouera pas physiquement le fichier sur votre appareil. Avec cette méthode, vous pouvez en fait créer un fichier de taille arbitraire, quel que soit l'espace disponible sur le périphérique, car elle crée un fichier "clairsemé".

Par exemple, remarquez qu'aucun espace disque dur n'est consommé avec cette commande :

### BEFORE
$ df -h | grep lvm
/dev/mapper/lvm--raid0-lvm0
                      7.2T  6.6T  232G  97% /export/lvm-raid0

$ truncate -s 500M 500MB.file

### AFTER
$ df -h | grep lvm
/dev/mapper/lvm--raid0-lvm0
                      7.2T  6.6T  232G  97% /export/lvm-raid0

Ainsi, en procédant ainsi, vous reporterez l'allocation physique jusqu'à ce que le fichier soit consulté. Si vous mappez ce fichier en mémoire, vous risquez de ne pas obtenir les performances attendues.

Mais c'est tout de même une commande utile à connaître. Par exemple, lors de l'évaluation des transferts utilisant des fichiers, la taille spécifiée du fichier sera toujours déplacée.

$ rsync -aHAxvP --numeric-ids --delete --info=progress2 \
       root@mulder.bub.lan:/export/lvm-raid0/500MB.file \
       /export/raid1/
receiving incremental file list
500MB.file
    524,288,000 100%   41.40MB/s    0:00:12 (xfr#1, to-chk=0/1)

sent 30 bytes  received 524,352,082 bytes  38,840,897.19 bytes/sec
total size is 524,288,000  speedup is 1.00

Answer 5

Où seek est la taille du fichier que vous voulez en octets - 1.

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