Par exemple pour le disque d'une machine virtuelle qu'on voudrait transmettre/copier/whatever, il peut être malin (ou juste amusant) de chercher à réduire la taille du fichier. On arrive donc à la notion de fichiers creux (sparse), où les blocs ne contenant que des zéros peuvent tout simplement ne pas être alloués par le système de fichiers.

Il faut donc d'abord mettre des zéros partout où le système invité de la VM n'a rien d'utile : zerofree. Petit outil simple, mais qui a besoin d'un FS non monté ou en ro. On passe donc en ro… (remount ne fonctionne pas : busy) :
echo u | sudo tee /proc/sysrq-trigger
Puis on peut lancer zerofree.

Là on se rend compte que la taille allouée ne diminue pas :
59G -rw-r--r-- 1 root root 59G mai 12 09:55 oleron.raw
59G de taille, 59G alloués… il faut donc… creuser des trous ! Et pour ça, rien de plus simple : fallocate -d
15G -rw-r--r-- 1 root root 59G mai 12 14:17 oleron.raw
Bien ! (à noter qu'on peut aussi utiliser cp --sparse=always, mais qu'il y a donc une copie du fichier (et dans ce test l'allocation était descendue à 20G au lieu de 15G avec fallocate, probablement une histoire de taille de bloc)).

Si l'on veut ensuite écrire cette image sur une clef USB, autant essayer de ne pas écrire ces trous de zéros (ce qui est pourtant le cas avec un dd simple). Pour cela on découvre l'option conv=sparse de dd. En testant je suis arrivé à cela (image de 64Gio, 20G alloués, sur clef USB3 190Mo/s) :
dd simple, bs=1M : 348,944 s, 180 MB/s
cp sparse (bs probablement 4k) : 6m55.131s (donc 415s)
dd sparse : 206,039 s, 305 MB/s
On remarque que la vitesse moyenne est plus grande que la vitesse d'écriture max constatée ! :) Bon et si on poussait le vice à faire deux clefs en parallèle ? 235,069 s, 267 MB/s !
Conclusion, avec tout cela on s'est bien amusé et on peut écrire 2 clefs de 64G utilisables (20G réels) en moins de 5 minutes :) Pour moi qui en ai 25 à faire, c'est pas si mal.

EDIT: 172,801 s, 363 MB/s avec l'image fallocate (qui fait donc 15G au lieu de 20G) en mono-dd sparse.