J'utilise la commande dd pour créer une clé USB amorçable à partir d'un fichier iso:
sudo dd if=~/Desktop/ubuntu.iso of=/dev/sdx bs=1MAprès avoir appuyé sur Entrée, il quitte momentanément et me donne:
915+0 records in 915+0 records out 959447040 bytes (959 MB) copied,
0.539375 s, 1.8 GB/sC'est donc comme courir en arrière-plan parce que je peux voir que le lecteur flash fonctionne. Finalement, il cessera de copier et je peux retirer le lecteur avec succès, mais la question est de savoir pourquoi la commande dd n'attend pas la fin de la copie. Pourquoi fonctionne-t-il en arrière-plan. Et comment puis-je faire attendre?
command-line
bash
Kir Ivlev
la source
la source
sync?syncpourrait attendre.dda également quelques options de synchronisation, par exempleconv=fsync. Cela dit, je n'ai jamais eu à l'utiliser/dev/sd*moi-même avec des lecteurs. Si vous avez littéralement utilisé/dev/sdxma supposition, vous auriez eu un fichier inutile de 959 Mo dans/dev(ramdisk) maintenant ...Réponses:
Malgré la croyance populaire,
ddc'est une commande parfaitement ordinaire, ce n'est pas plus bas quecatoucp. Votre commande lit à partir du cache de disque et écrit dans les tampons de disque comme toute autre commande.Afin de vous assurer que les données sont entièrement écrites sur le support physique, vous devez appeler
sync. La commandesyncvide tous les tampons de sortie sur le ou les disques. Lorsque lasynccommande revient, les données ont été entièrement écrites.La plupart du temps, vous n'avez pas besoin d'appeler
sync, car le démontage d'un système de fichiers fait le même travail. Lorsque laumountcommande revient ou lorsque vous recevez un message de confirmation après avoir cliqué sur «Éjecter», les tampons ont été écrits sur le disque. Ici, vous écrivez directement sur le disque sans passer par un système de fichiers monté, vous devez donc vider explicitement le tampon.Notez qu'au lieu de
dd, vous pouvez utilisertee. Cela a deux avantages: il y a moins de risque d'inverser la source et la destination en raison d'une faute de frappe, et c'est probablement un peu plus rapide .la source
sudo tee /dev/sdx >/dev/null, sinon le processus de copie serait encore très lent en raison de l'écriture de données sur la sortie de la console.synccommande, mais ils font le même travail sous le capot.conv=fdatasync, laddcommande n'attend pas pour terminer jusqu'à ce que les données soient écrites sur le disque, comme l'OP l'a demandé. De plus, lasynccommande planifie une opération de synchronisation, mais elle revient immédiatement; il n'attend pas pour revenir avant que les données soient écrites sur le disque.ddn'attendra pas que le cache soit vidé sansconv=fdatasyncetc. mais sur un Linux non ancien vous avez tort desyncne pas attendre. Vous pouvez voir coreutilssync(8)faire lesync(2)syscall . Lasync(2)page de manuel indique "Avant la version 1.3.20, Linux n'attendait pas la fin des E / S avant de revenir." ilsync(8)ne reviendra donc pas tant que le disque n'aura pas reconnu les écritures (ou qu'une erreur ne se produira).Essaye ça:
Le
conv=fdatasyncindiqueddd'utiliser les options spéciales pour s'assurer que les données sont écrites sur le périphérique physique.la source