Gnome, nautilus copia i file su USB si ferma al 100% o quasi

Ho avuto problemi simili prima ma non ricordo come l'ho risolto.

Quando provo a copiare qualcosa su chiavetta USB, con FAT, si ferma vicino alla fine, a volte al 100%. E, naturalmente, quando trasferisco la memory stick da qualche altra parte, non contiene file completi. (il file è un film!)

Ho provato a montare il dispositivo con mount -o flush, ma ho lo stesso problema.

Inoltre, ho formattato la chiavetta USB con la nuova partizione FAT ...

Hai idea di cosa faccio?

ps Credo che non sia correlato al sistema operativo, che è Debian, e credo che il coping dall'unità SSD non lo blocchi.

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 il parametro kernel vm.dirty_bytessu qualcosa di simile 15000000(15 MB). Ciò significa che l'applicazione non può ottenere più di 15 MB prima del suo effettivo progresso. (Puoi cambiare i parametri del kernel al volo con, sudo sysctl vm.dirty_bytes=15000000ma farli rimanere durante un riavvio richiede la modifica di un file di configurazione come /etc/sysctl.confche potrebbe essere specifico per la tua distribuzione.)

Un effetto collaterale è che il tuo computer potrebbe avere un throughput di scrittura dei dati inferiore 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 dirty_bytessu 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".

Vecchia domanda, ma sembra che il problema si presenti ancora. L'impostazione del buffer su 15 MB, come suggerito qui, non ha funzionato su Ubuntu 19.04 e ha fermato il mio sistema.

Stavo cercando di copiare un file da 1,5 GB su un'unità FAT32 da 16 GB vuota (appena formattata). L'ho lasciato funzionare per circa 10 minuti solo per vedere se sarebbe finito, senza fortuna.

La riformattazione in NTFS consente di terminare l'operazione in meno di 10 secondi. Non so perché questo sarebbe importante perché FAT32 dovrebbe consentire qualcosa di meno di 2 GB, ma sembrava funzionare bene. Non è una soluzione ideale per le unità che si desidera utilizzare con MacOS, ma una soluzione semplice per tutti gli altri casi d'uso. Immagino che exFAT avrebbe funzionato in modo simile, ma non l'ho provato.