Perché quando si copia su un'unità esterna la finestra di avanzamento non è corretta

Sentiti libero di modificare il titolo per spiegare meglio cosa ho intenzione di scrivere qui.

Quando copio file di grandi dimensioni su una pen drive, ad esempio, la finestra di avanzamento mostra una stima che la maggior parte delle volte non fallisce nel mostrare il tempo reale e la percentuale di completamento, ma ci sono casi in cui dice che tutto è finito e la finestra di avanzamento chiude. Vado a estrarre la pen drive e dice che è ancora in uso. Dopo aver controllato la pen drive vedo che sta ancora copiando i file ma non c'è finestra di progresso che mostra questo.

Non succede solo con file di grandi dimensioni, ma anche con molti file di piccole dimensioni. Se li copio, la barra di avanzamento potrebbe dire 15 secondi per esempio e finire in quel momento, ma il tempo reale potrebbe essere 1 minuto e per i successivi 45 secondi dovrò davvero guardare la luce nella pen drive per vedere se ci è vera attività su di esso.

Non voglio sapere come risolverlo poiché ho letto quanto può essere profonda una correzione per questo. Quello che voglio sapere è perché la finestra di avanzamento mostra una stima che non corrisponde al processo di copia.

Dipende dalla cache nell'unità esterna?

Dimensione del file e quantità di influenza del file sulla stima corretta. Ad esempio 1 file da 4 GB o 1000 file da 4 MB.

Esistono opzioni di configurazione che possono modificare il comportamento.

Ci sono altre domande simili a questa, come la copia di file su chiavette USB mai finite, ma sono più focalizzato sulla meccanica sul perché si comporterebbe così.

Suppongo che tu stia usando Nautilus come file manager e, in tal caso, ci sono bug di vecchia data a riguardo. Troppo assurdo per menzionare l'effetto di Menta, Fedora, Red Hat e simili. Ubuntu non è senza questo stesso problema.

Alcuni suggeriscono di disattivare la visualizzazione delle miniature. Altri ripongono le loro speranze nel "kernel più recente", ma questo esiste ancora.

Il problema = Inizia velocemente, poi va più lentamente Questo perché quando montato con asincrono scriverà nella cache, quando la cache è piena vedrai la velocità di scrittura "Reale".

Il lavoro sembra essere sudo cp /filetobecopied /dev/nameofdevice

un altro postato qui dice che "copiare in pezzi" funziona. Non confermato da parte mia.

Questa è anche una bella risposta con una soluzione: https://unix.stackexchange.com/a/181236 Dice:

La ragione per cui accade in questo modo è che il programma dice "scrivi questi dati" e il kernel di Linux lo copia in un buffer di memoria che è in coda per andare su disco, e quindi dice "ok, fatto". Quindi il programma pensa di aver copiato tutto. Quindi il programma chiude il file, ma improvvisamente il kernel lo fa attendere mentre quel buffer viene espulso sul disco.

Quindi, sfortunatamente, il programma non può dirti quanto tempo ci vorrà per svuotare il buffer perché non lo sa.

Se si desidera provare alcuni trucchi per utenti esperti, è possibile ridurre le dimensioni del buffer utilizzato da Linux impostando / proc / sys / vm / dirty_bytes su qualcosa come 15728640 (15 MB). Ciò significa che l'applicazione non può ottenere più di 15 MB prima del suo effettivo progresso.

Un effetto collaterale è che il tuo computer potrebbe avere un throughput di scrittura dei dati più basso con questa impostazione, ma nel complesso trovo utile vedere che un programma è in esecuzione da molto tempo mentre scrive molti dati rispetto alla confusione di avere un il programma sembra terminato con il suo lavoro, ma il sistema è in grave ritardo mentre il kernel fa il vero lavoro. L'impostazione di dirty_bytes su un valore ragionevolmente piccolo può anche aiutare a evitare che il tuo sistema non risponda quando sei a corto di memoria libera ed esegui un programma che improvvisamente scrive molti dati.

Ma non impostarlo troppo piccolo! Uso 15 MB come stima approssimativa che il kernel può scaricare il buffer su un normale disco rigido in 1/4 di secondo o meno. Mantiene il mio sistema "ritardato".