Depuis le wiki Arch Linux: https://wiki.archlinux.org/index.php/USB_flash_installation_media

# dd bs=4M if=/path/to/archlinux.iso of=/dev/sdx status=progress && sync

[...] Ne manquez pas la synchronisation pour terminer avant de retirer la clé USB.

J'aimerais savoir

Qu'est ce que ça fait?
Quelles sont les conséquences s'il est omis?

Remarques

ddcommande utilisée avec facultatif status=progress:

tar -xzOf archlinux-2016-09-03-dual.iso | dd of=/dev/disk2 bs=4M status=progress && sync

Ou utiliser pvpour progresser

tar -xzOf archlinux-2016-09-03-dual.iso | pv | dd of=/dev/disk2 bs=4M && sync

dd storage bootable removable-storage

— Jonathan Komar
source

Le ddne contourne pas les caches de disque du noyau lorsqu'il écrit sur un périphérique, donc une partie des données peut ne pas encore être écrite sur la USBclé une fois ddterminée. Si vous débranchez votre USBbâton à ce moment, le contenu du USBbâton serait incohérent. Ainsi, votre système pourrait même ne pas démarrer à partir de cette USBclé.

Sync vide toutes les données encore en cache sur le périphérique.

Au lieu d'invoquer, syncvous pouvez utiliser fdatasync ddl'option de conversion de:

fdatasync

écrire physiquement les données du fichier de sortie avant de terminer

Dans votre cas, la commande serait:

tar -xzOf archlinux-2016-09-03-dual.iso | \
dd of=/dev/disk2 bs=4M status=progress conv=fdatasync

Le conv=fdatasyncfait ddeffectivement appeler le fdatasync()système à la fin du transfert juste avant les ddsorties (j'ai vérifié cela avec ddles sources de).

Cela confirme que ddcela ne contournerait ni ne viderait les caches, sauf indication explicite de le faire.

— Serge
source

Merci pour votre contribution, mais je ne suis pas sûr que cette déclaration soit correcte. Le ddne contourne pas les caches de disque du noyau lorsqu'il écrit sur un périphérique . Lors de l'écriture dans un fichier (sur la couche du système de fichiers du noyau), les choses sont mises en cache. Cependant, je suis préoccupé par l'écriture sur des appareils. Veuillez fournir une source pour cette déclaration si vous le pouvez, car c'est le pivot de cette question. Si la valeur est true, cela fournirait une raison valable de s'exécuter syncaprès une opération dd-to-device .

— Jonathan Komar

Oui, il est mis en cache. La mise en cache se produit à l'intérieur de l'infrastructure de périphérique de bloc du noyau. Les opérations sur les fichiers elles-mêmes ne sont pas mises en cache. l'interface du périphérique de bloc sous-jacent effectue l'encaissement. source: lxr.free-electrons.com/source/block/blk-flush.c

— Serge

@ macmadness86 voir la réponse mise à jour

— Serge

Je préfère utiliser oflag=sync, donc la progression produit la vitesse de transfert réelle et non celle mise en cache (donc va un 10 Mo / s stable au lieu d'une seconde 100 Mo / s, puis 10 secondes de décrochage).

— Bart Polot

L'écriture sur un périphérique de bloc contourne complètement VFS. En d'autres termes: l'écriture dans un fichier peut être mise en cache par le noyau (et c'est généralement le cas) mais l'écriture sur un périphérique n'est jamais mise en cache par le noyau (et elle ne peut pas).

— Eric

Depuis la page de manuel sync (1): "sync - Synchroniser les écritures mises en cache sur le stockage persistant". syncS'assure essentiellement que toutes vos données sont écrites sur la clé à partir du cache.

— Schaiba
source

Je ne vois pas où dans votre question apparaît la partie sur la lumière qui est allumée.

— schaiba

Pourquoi la synchronisation est-elle si importante lors de la création d'une clé USB Linux amorçable?

Remarques