Pourquoi spécifier la taille de bloc lors de la copie d'appareils de taille finie?

14

Dans les didacticiels en ligne, il est souvent suggéré d'utiliser la commande suivante pour copier un CD-ROM dans une image ISO:

$ dd if=/dev/dvd of=foobar.iso bs=2048

Pourquoi la taille d'octet doit-elle être spécifiée? Je remarque qu'en fait 2048 est la taille d'octet standard pour les images CDROM mais il semble que cela ddne spécifie pas bs=ou count=fonctionne aussi.

Dans quelles circonstances serait-il problématique de ne pas spécifier bs=ou count=lors de la copie à partir d'un périphérique de taille finie?

linux hard-disk dd cloning

— dotancohen
source

12

Quand dd convient-il pour copier des données? (ou, quand sont read () et write () partial) souligne une mise en garde importante lors de l'utilisation count: ddpeut copier des blocs partiels, donc une fois donné, countil s'arrêtera après le nombre de blocs donné, même si certains blocs étaient incomplets. Vous pouvez donc vous retrouver avec moins de bs * countoctets copiés, sauf indication contraire iflag=fullblock.

La taille de bloc par défaut pour dd est de 512 octets. countest une limite; comme votre question l'indique, elle n'est pas requise lors de la copie d'un périphérique de taille finie et est vraiment destinée à copier uniquement une partie d'un périphérique.

Je pense qu'il y a deux aspects à considérer ici: les performances et la récupération de données.

En ce qui concerne les performances, vous souhaitez idéalement que la taille de bloc soit au moins égale et multiple de la taille de bloc physique sous-jacente (d'où 2048 octets lors de la lecture d'un CD-ROM). En fait, de nos jours, vous pouvez également spécifier des tailles de bloc plus grandes pour donner aux systèmes de mise en cache sous-jacents une chance de mettre les choses en mémoire tampon pour vous. Mais augmenter la taille des blocs signifie ddutiliser beaucoup plus de mémoire et cela pourrait être contre-productif si vous copiez sur un réseau en raison de la fragmentation des paquets.

En ce qui concerne la récupération de données, vous pouvez récupérer plus de données à partir d'un disque dur défaillant si vous utilisez des tailles de bloc plus petites; c'est ce que dd-rescuefont des programmes tels que automatiquement: ils lisent initialement les gros blocs, mais si un bloc échoue, ils le relisent avec des tailles de bloc plus petites. ddne le fera pas, il échouera tout le bloc.

— Stephen Kitt
source

2

Performance surtout; écrire une image de partition sur une carte SD, par exemple, en utilisant dd bs=4m iflag=fullblockvs dd bs=1111et notez les débits de données considérablement plus élevés que la première vous donnera. Cela est dû au fait que le premier correspond aux tailles de bloc naturelles sur la carte SD, tandis que le second nécessite que le contrôleur SD fasse beaucoup de lecture, de copie et de reflashing pour écrire des blocs physiques partiels. L'importance de fullblockne doit pas être sous-estimée, soit dit en passant, car sans elle, ce bsn'est qu'un maximum et des lectures partielles pourraient conduire à des désalignements ultérieurs persistants.

— Jason C

6

Il y a un peu de culte du fret autour dd. À l'origine, il y avait deux bogues cpqui causaient des problèmes: il détectait mal les fichiers comme rares lorsqu'ils étaient signalés avec une taille de bloc autre que 512 (Linux utilisait une taille de bloc de 1024), et il n'effaçait pas les blocs vides de la destination lors de la copie à partir d'un fichier épars vers un périphérique de bloc.

Vous pouvez trouver quelques références à cela dans les premières archives de la liste de diffusion Linux .

Les gens se sont donc habitués à ce que dd soit la bonne façon de gérer les images disque, et cp est tombé à l'eau. Et puisque dd utilise une taille de bloc par défaut de 512, il est lent (plus lent que cp sur les systèmes modernes). Mais la taille du bloc à utiliser n'est pas évidente. Probablement dans votre cas, quelqu'un a lu que 2048 est la taille de bloc "naturelle" pour un CD-ROM (c'est-à-dire que les CD-ROM sont divisés en secteurs de 2 352 octets contenant 2 048 octets de données avec des informations de correction d'erreur) et a décidé que cela est la "bonne" taille à utiliser avec dd, alors qu'en fait vous obtiendriez probablement des résultats plus rapides si vous utilisiez une taille de bloc (modérément) plus grande. En fait, GNU cp utilise une taille de bloc par défaut de 64 Ko pour cette raison.

tl; dr: cp /dev/dvd foobar.iso devrait fonctionner correctement. La taille de bloc par défaut ddest 512. Le seul effet que le laisser seul est susceptible d'avoir dans la plupart des circonstances modernes est de ralentir le processus de copie.

— Aléatoire832
source

cela pourrait avoir changé, de toute façon GNU cp utilise une taille de bloc de 128k par défaut (pas 64k), voir eklitzke.org/efficient-file-copying-on-linux

— apurkrt

5

Changer la taille du bloc est un bon moyen de changer la quantité de mémoire tampon ou de lecture / écriture à la fois.

Ne se rapporte pas vraiment au fait qu'il s'agisse d'un véritable périphérique de bloc ou d'un périphérique infini / virtuel. Il s'agit de la quantité que vous souhaitez stocker en mémoire avant ddde l'écrire. bs=définit à la fois ibs=(la quantité de données lues à la fois) et obs=(la quantité de données écrites à la fois). Plus il est élevé, obs=plus il ibs=faudra d'itérations avant d'avoir suffisamment de données pour ddcommencer à écrire dans la destination.

count=ne dépend pas d'autre chose que de ce que vous voulez faire. Il contrôle combien de "blocs" (mesurés par ibs=) seront nécessaires pour ddconsidérer que son travail est terminé.

— Bratchley
source

Remarque Stephens au point de ddcopier des blocs partiels - ce n'est pas toujours bs * count.

— Drav Sloan

Notez que sur certains systèmes Unix, vous devez lire un multiple de la taille de bloc native; ddsans bs=2048ou un multiple de celui-ci donnerait une erreur lors de la lecture à partir d'un lecteur de cdrom de périphérique bloc.

— wurtel

2

L'utilisation de l'option de taille de bloc sur ddspécifie efficacement la quantité de données à copier dans la mémoire du sous-système d'E / S d'entrée avant d'essayer de réécrire dans le sous-système d'E / S de sortie. La sortie est la même (car tout le disque est copié), les morceaux sont simplement lus à la taille différente que vous spécifiez (la plupart des ddimplémentations vont avec une taille de bloc par défaut de 512 octets).

Si vous disposez de grandes quantités de mémoire disponible et augmentez la taille des blocs, des blocs de données plus volumineux peuvent être lus successivement, mis en mémoire tampon et vidés vers la destination de sortie. Une taille de bloc inférieure nécessite plus de surcharge pour chaque lseek, memset, etc.

Votre kilométrage peut varier en fonction de votre emplacement if=et de votre of=configuration, ainsi que du matériel que vous utilisez, si votre mémoire est insuffisante, etc.

— Drav Sloan
source

1

Le bs = représente la taille du bloc à lire ou à écrire. Laisser le champ intact ou ne pas le spécifier peut sembler faire le même travail de copie mais il y a un fait caché à l'utiliser. Par exemple,

Ayant 1000000000000000 fichiers avec chacun de seulement 1 ~ 10 ko.
Avoir un seul fichier pour 10 Go

Dans le premier cas, l'utilisation d'une taille de bloc inférieure s'est avérée augmenter la vitesse de copie. Alors que dans ce dernier, une taille de bloc plus élevée a été une meilleure option car elle augmente la taille du secteur en laissant moins de sector changecommandes, ce qui se traduit généralement par des opérations d'E / S plus rapides.

— Snazzy Sanoj
source