Considérez un périphérique de bloc brut de 100 Mo comme exemple simple. Soit 204800 blocs de 512 octets chacun pour un total de 102760448 octets.
Le défi est de décaler les premiers 98 Mo (blocs 200704) de sorte qu'il y ait un écart de 2 Mo (4096 blocs) devant lui. Pour le faire sur place, rien n'est écrit dans un secteur qui n'a pas été lu. Une façon d'y parvenir consiste à introduire un tampon:
$ dd if=/dev/sdj2 count=200704 | mbuffer -s 512 -b 4096 -P 100 | dd of=/dev/sdj2 seek=4096
On s'attend à ce mbuffer
qu'il stocke 4096 blocs avant de transmettre quoi que ce soit à l'écrivain, garantissant ainsi que rien n'est écrit dans une zone qui n'a pas été lue et que l'écrivain accuse un retard sur le lecteur par la taille du tampon. Le tampon doit permettre au lecteur et à l'écrivain de fonctionner aussi rapidement que possible dans ces constriants.
Cependant, cela ne semble pas fonctionner de manière fiable. J'ai essayé d'utiliser de vrais appareils mais ça ne marche jamais sur eux, alors que les expériences avec un fichier fonctionnaient sur ma box 64 bits mais pas sur ma box 32 bits.
Tout d'abord, quelques préparatifs:
$ dd if=/dev/sdj2 count=200704 | md5sum
0f0727f6644dac7a6ec60ea98ffc6da9
$ dd if=/dev/sdj2 count=200704 of=testfile
Cela ne fonctionne pas:
$ dd if=/dev/sdj2 count=200704 | mbuffer -s 512 -b 4096 -P 100 -H | dd of=/dev/sdj2 seek=4096
summary: 98.0 MiByte in 4.4sec - average of 22.0 MiB/s
md5 hash: 3cbf1ca59a250d19573285458e320ade
Cela fonctionne sur un système 64 bits mais pas sur un système 32 bits:
$ dd if=testfile count=200704 | mbuffer -s 512 -b 4096 -P 100 -H | dd of=testfile seek=4096 conv=notrunc
summary: 98.0 MiByte in 0.9sec - average of 111 MiB/s
md5 hash: 0f0727f6644dac7a6ec60ea98ffc6da9
Comment cela peut-il être fait de manière fiable?
Remarques
J'ai lu d'autres questions sur la mise en mémoire tampon et regardé pv
, buffer
et mbuffer
. Je ne pouvais que faire fonctionner ce dernier avec la taille de tampon requise.
L'utilisation du stockage intermédiate est une solution évidente au problème qui fonctionne toujours, mais ce n'est pas pratique quand une capacité de réserve suffisante n'est pas disponible.
Testez les plates-formes exécutant Arch Linux avec la mbuffer
version 20140302.
mbuffer
devrait en fait forcer le second dd
à prendre du retard pour le premier et vous n'avez besoin que de suffisamment de RAM pour tamponner la taille du décalage. Dommage dd
ne prend pas en charge la lecture et l'écriture des blocs dans l'ordre inverse car cela éliminerait le problème!
-H
argument active cette fonctionnalité).
mbuffer
du tout? Pourquoi ne pas plutôt fairedd
lire le contenu entier du périphérique de bloc en une seule fois en utilisantdd bs=102760448
? Bien sûr, d'une manière ou d'une autre, il est mis en mémoire tampon dans la RAM.