Comment créer des fichiers arbitrairement lourds pour tester son débit ?

/dev/random est un fichier spécial qui sert de générateur de nombres aléatoires.
/dev/urandom est plus rapide, mais l'aléa produit est donc de moins bonne qualité.
/dev/zero ne contient que des zéros.

Voici la commande, sous linux pour créer un fichier rempli de zéro, donc facilement compressible :
dd if=/dev/zero of=/tmp/1Mo.zero bs=1KB count=100000
100000+0 enregistrements lus
100000+0 enregistrements écrits
100000000 octets (100 MB) copiés, 0,911139 s, 110 MB/s
C'est un fichier de 100 Mo, pour un fichier plus gros ou plus petit, il suffit de modifier "count" qui compte le nombre de bloc de 1 Ko.

Voici la même commande, pour créer un fichier rempli de données pseudo-aléatoires donc non compressible :
dd if=/dev/urandom of=/tmp/1Mo.random bs=1KB count=100000
100000+0 enregistrements lus
100000+0 enregistrements écrits
100000000 octets (100 MB) copiés, 9,44209 s, 10,6 MB/s

Pour un fichier de 1024 octets :
dd if=/dev/urandom of=./1Kio.dat bs=2b count=1
1+0 enregistrements lus
1+0 enregistrements écrits
1024 octets (1,0 kB) copiés, 0,000275317 s, 3,7 MB/s

Je vais l'utiliser pour générer les fichiers de https://testdebit.info/

Je pense proposer les tailles suivantes (générées en random et zerro afin de voir l'impact d'une compression) :

1Mo.rand
2Mo.rand
5Mo.rand
10Mo.rand
20Mo.rand
50Mo.rand
100Mo.rand
200Mo.rand
500Mo.rand
1000Mo.rand
1000Mo-1.rand
1000Mo-2.rand
1000Mo-3.rand
1000Mo-4.rand
1000Mo-5.rand
1000Mo-6.rand
1000Mo-7.rand
1000Mo-8.rand
1000Mo-9.rand
1Mo.zero
5Mo.zero
20Mo.zero
100Mo.zero
500Mo.zero
1Mo.txt
5Mo.txt
20Mo.txt
1Mo.jpg
5Mo.jpg
20Mo.jpg
5Mo.png (je me suis cassé la tête pour que ces photos fassent exactement 5 Mo et 20 Mo au bit prés)
20Mo.png

Total :
- 1888 Mo pour les fichiers RAND (les fichiers 1000Mo-1.rand et suivants sont des liens de 1000Mo.rand)
- 626 Mo pour les fichiers .zero
- 26 Mo pour les fichiers .txt
- 26 Mo pour les fichiers .jpg
- 25 Mo pour les fichiers .png
Total : 2591 Mo

=> Un serveur avec 4 Go de RAM peux avoir ces fichiers en RAM ce qui permet d'avoir de très bonnes performances.

Le bit 1 de quoi donc ? 

La taille d'un fichier est définie par la différence entre la position 0 et celle de son dernier octet de données.
C'est pour ça qu'en avançant dans le fichier de n-1 ko et en écrivant 1 ko, le fichier fait au final n ko.

Ceci étant dit, le système de fichiers n'est pas dupe de ce petit manège.

Si je crée un fichier contenant 16 Ko de données ...
$ dd if=/dev/urandom of=/tmp/random bs=1K count=16
16+0 enregistrements lus
16+0 enregistrements écrits
16384 octets (16 kB) copiés, 0,00830498 s, 2,0 MB/s

... il fait bien 16 ko, et on voit que 32 blocs de 512 octets (soit 16 ko) lui ont bien été alloués :
$ stat /tmp/random
  File: « /tmp/random »
  Size: 16384           Blocks: 32         IO Block: 4096   fichier
Device: fd00h/64768d    Inode: 391983      Links: 1
(...)

Si je supprime maintenant le fichier pour invalider son i-nœud, et que je recommence l'opération en n'écrivant effectivement qu'un seul ko de données ...
$ rm /tmp/random
$ dd if=/dev/urandom of=/tmp/random bs=1K seek=15 count=1
1+0 enregistrements lus
1+0 enregistrements écrits
1024 octets (1,0 kB) copiés, 0,000592388 s, 1,7 MB/s

... il fait toujours 16 ko, mais seuls 8 blocs de 512 octets (soit 4 ko = la taille minimale d'un bloc d'E/S) lui ont effectivement été alloués :
$ stat /tmp/random
  File: « /tmp/random »
  Size: 16384           Blocks: 8          IO Block: 4096   fichier
Device: fd00h/64768d    Inode: 391983      Links: 1
(...)

Ce qui dans l'absolu ne change rien, puisque si je demande à lire le fichier, l'OS va me retourner 15 359 zéros avant de me donner à lire le dernier ko de données utiles :
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00003c00  30 ff ea 85 e0 e4 94 c2  22 ae fa a8 8c 8d 04 35  |0......."......5|
(...)
00003ff0  a5 ab 9c 1d 3d 5a 4c 13  8b cb 1d ac 4e 67 4c 55  |....=ZL.....NgLU|
00004000

Mais bon, c'est un cas un peu tordu.
Du fait de la taille minimale d'un bloc d'E/S, un fichier occupe généralement plus d'espace disque que sa taille effective (ou logique).