attendere che il comando dd scriva completamente sul disco

Sto usando il comando dd per creare un usb avviabile dal file ISO:

sudo dd if=~/Desktop/ubuntu.iso of=/dev/sdx bs=1M

Dopo aver premuto invio si esce momentaneamente e mi dà:

915+0 records in 915+0 records out 959447040 bytes (959 MB) copied,
0.539375 s, 1.8 GB/s

Quindi è come correre in background perché vedo che l'unità flash funziona. Alla fine smetterà di copiare e posso rimuovere l'unità correttamente, ma la domanda è perché il comando dd non aspetta che la copia finisca. Perché viene eseguito in background. E come posso farlo aspettare?

command-line bash

— Kir Ivlev
fonte

Ci hai provato sync?

— Choroba,

@choroba Ha senso eseguire "sync" se il sistema sta già scrivendo dati sull'unità flash?

— Kir Ivlev,

Non sono sicuro, byt syncpotrebbe aspettare.

— Choroba,

ddha anche alcune opzioni di sincronizzazione, ad esempio conv=fsync. Detto questo, non ho mai dovuto usarlo con le /dev/sd*unità da solo. Se avessi letteralmente usato la /dev/sdxmia ipotesi sarebbe stato che tu avessi un file inutile da 959 MB in /dev(ramdisk) ora ...

— frostschutz

@frostschutz Ho usato / sdc per la mia unità flash

— Kir Ivlev il

Risposte:

Nonostante la credenza popolare, ddè un comando perfettamente ordinario, non è più di basso livello di cato cp. Il tuo comando legge dalla cache del disco e scrive nei buffer del disco come qualsiasi altro comando.

Per assicurarsi che i dati siano completamente scritti sul supporto fisico, è necessario chiamare sync. Il comando syncscarica tutti i buffer di output sui dischi. Quando il synccomando ritorna, i dati sono stati completamente scritti.

sudo dd if=~/Desktop/ubuntu.iso of=/dev/sdx bs=1M; sync

Il più delle volte, non è necessario chiamare sync, poiché lo smontaggio di un filesystem fa lo stesso lavoro. Quando viene umountrestituito il comando o quando viene visualizzato un messaggio di conferma dopo aver fatto clic su "Espelli", i buffer sono stati scritti sul disco. Qui, stai scrivendo direttamente sul disco senza passare attraverso un filesystem montato, quindi devi svuotare esplicitamente il buffer.

Nota che invece di dd, potresti usare tee. Questo ha due vantaggi: c'è un minor rischio di invertire l'origine e la destinazione a causa di un errore di battitura, ed è probabilmente leggermente più veloce .

<~/Desktop/ubuntu.iso sudo tee /dev/sdx >/dev/null; sync

— Gilles 'SO- smetti di essere malvagio'
fonte

Che ne dici dei pulsanti / icone "Espelli" o "Rimozione sicura". Non chiamerebbero anche la sincronizzazione prima di dare la notifica "OK per rimuovere"?

— user68186

Probabilmente vuoi usarlo sudo tee /dev/sdx >/dev/null, altrimenti il processo di copia sarebbe comunque molto lento a causa della scrittura dei dati nell'output della console.

— Lekensteyn,

@ user68186 Non chiamano il synccomando, ma fanno lo stesso lavoro sotto il cofano.

— Gilles 'SO- smetti di essere malvagio' il

Questa risposta è sbagliata Senza conv=fdatasync, il ddcomando non attende di terminare fino a quando i dati non vengono scritti sul disco, come richiesto dall'OP. Inoltre, il synccomando pianifica un'operazione di sincronizzazione, ma restituisce immediatamente; non attende di tornare fino a quando i dati non vengono scritti sul disco.

— vy32,

@ vy32 hai ragione ddnon aspetterai che la cache venga svuotata senza conv=fdatasyncecc. ma su Linux non antico non hai ragione di syncnon aspettare. Puoi vedere i coreutils che sync(8)fanno la sync(2)syscall . La sync(2)man-page dice "Prima della versione 1.3.20 Linux non aspettava il completamento dell'I / O prima di tornare." quindi sync(8)non ritornerà fino a quando il disco non riconoscerà le scritture (o verrà generato un errore).

— Anon,

Prova questo:

sudo dd if=~/Desktop/ubuntu.iso of=/dev/sdx conv=fdatasync bs=1m

La conv=fdatasyncdice dddi usare le opzioni speciali per fare in modo che i dati vengono scritti nel dispositivo fisico.

— vy32
fonte