Ubuntu danneggia le unità USB?

74

Ogni volta che smonto un'unità USB con Nautilus e la collego a una macchina Windows, ricevo un avviso che l'unità deve essere riparata.

(lo stesso messaggio come in questo screenshot)

Per più di 10 anni lavorando con Windows non ho mai avuto un'unità USB corrotta o danneggiata, ma negli ultimi due anni tre delle mie unità USB sono diventate inattive, quindi non posso provarlo, ma è ovvio che questo è legato al comportamento di (disinstallazione) di Ubuntu .

Un amico mi ha detto che posso prevenire tali danni usando udisks e sync, ma spero che non sia questo il modo di farlo, montando unità con comandi shell nel 2016.

— jan6352781
fonte

1

Vorrei provare due test per capire la causa principale: 1) È possibile impedire la visualizzazione dell'errore se si chiama syncin una shell prima di smontare in Ubuntu? (improbabile) 2) Prova a scrivere un solo file alla volta, smonta, quindi controlla se questo file può essere letto su Windows e il suo contenuto è aggiornato, nonostante sia stato visualizzato questo avviso. 2) significa che il problema è molto probabilmente con Windows che è pignolo dicendo "abbiamo trovato errori" su alcuni problemi non reali.

— Ari

2

Non credere alle persone quando ti dicono che Linux non corromperà le tue unità. Può. Su Ubuntu 15, la semplice copia del file seguita dal riavvio mi ha dato costantemente errori in chkdsk in questo modo:

Stage 2: Examining file name linkage ...     Found corrupt basic file structure for "<0x32,0x1e63>"         ... queued for offline repair.     Found an unneeded link ($FILE_NAME: ???) in index "$I30" of directory "\ <0x5,0x5>"         ... queued for offline repair.     Found missing Index entry for file "<0x32,0x1e63>" from index "\??\D:\found.000" of directory "$I30"         ... queued for offline repair.

— Mehrdad,

1

^ ... per non parlare, questo non era nemmeno su un'unità flash, era sul mio SSD principale. Un nuovissimo SSD. Ed è successo ogni volta che non ho aggiunto un sacco di I / O extra dopo la copia del file. In altre parole, l'implementazione di NTFS di Linux è interrotta, tanto quanto i suoi fan vorranno negarlo ed evitare di crederci.

— Mehrdad,

12

È un filesystem NTFS? FAT32? Puoi riprodurlo in modo affidabile?

— Braiam,

2

Cosa c'è di così brutto con il montaggio di unità con comandi shell ? ¯＼(o_o)/¯

— Ulidtko,

104

Nessun problema Ubuntu non ha danneggiato l'unità USB. Ma non utilizziamo flag di bit scarsamente documentati di un file system FAT32, FAT16 o NTFS. Su Windows questi flag indicano un file system eventualmente danneggiato quando non abbiamo smontato correttamente l'unità o si è verificato un errore I / O.

Quei bit si trovano in una voce riservata di una tabella delle partizioni FAT. Secondo un documento interno Microsoft del 2004, lo scopo di questi bit è:

ClnShutBitMask:
Se il bit è 1, il volume è "pulito". Il volume può essere montato per l'accesso. Se il bit è 0, il volume è "sporco" a indicare che un driver del file system FAT non è stato in grado di smontare correttamente il volume (durante un'operazione di montaggio precedente). Il contenuto del volume deve essere scansionato per rilevare eventuali danni ai metadati del file system.

HrdErrBitMask:
Se questo bit è 1, non si sono verificati errori di lettura / scrittura sul disco. Se questo bit è 0, l'implementazione del driver del file system ha riscontrato un errore I / O del disco sul volume l'ultima volta che è stato montato, il che indica che alcuni settori potrebbero essere andati male. Il contenuto del volume deve essere scansionato con un'utilità di riparazione del disco che esegue l'analisi della superficie su di esso alla ricerca di nuovi settori danneggiati.

Alcuni anni fa si è discusso con gli sviluppatori del file system del kernel su come superarlo, ma non sono stato in grado di seguire i risultati. Apparentemente non è diventato un kernel recente.

Poiché è coinvolto solo un bit flag, ma in generale i nostri dati dovrebbero essere in perfetta forma, possiamo ignorare i problemi di avviso di Windows su quelle unità che avevamo precedentemente utilizzato in Ubuntu.

— Takkat
fonte

3

Non ho mai avuto questi errori in queste unità quando ho effettivamente smontato in modo sicuro le unità - sei sicuro che manchi il supporto per questi bit?

— Thomas Ward

5

@ThomasW. Questi bit sono piuttosto oscuri ma a volte ho questi errori con le mie unità USB formattate Ubuntu sul mio posto di lavoro Windows 7. Finora non ho visto alcun modello utile. L'unica cosa che posso dire è che smonto / espelle sempre correttamente le unità. Il test non è facile perché a casa senza Windows, al lavoro senza Ubuntu.

— Takkat,

Il titolo è falso.

— Matthew Rock

@MatthewRock: meglio?

— Takkat,

Sì, è meglio

— Matthew Rock

74

Questo è principalmente un problema con Windows. Pensa che sia l'unico sistema operativo al mondo e agisce se rileva qualcosa che non capisce.

Solo perché Windows dice che è necessario riparare l'unità non lo rende vero.

Tutte le mie unità utilizzate con Ubuntu ricevono questo messaggio da Windows, dico solo noe funzionano bene con Windows.

In breve, non c'è niente di sbagliato nell'unità, è solo che c'è qualcosa lì che Windows non capisce e la sua risposta è distruggerlo.

Non repairguidare, lo formatterà senza dirtelo e perderai tutti i dati sul disco.

— Mark Kirby
fonte

40

1. La riparazione non formatta, la riparazione salva i dati allocati in una cartella. Per me sembra che Ubuntu non completi correttamente il processo di scrittura.

— jan6352781

10

2. La maggior parte delle unità USB è formattata FAT32, sviluppata da Microsoft, quindi perché Windows dovrebbe essere l'unico sistema a "non capire" qualcosa ??

— jan6352781

17

-1 perché è infondato e sbagliato. Ho visto Ubuntu 15 corrompere il mio volume NTFS (sì, so che non mi crederai, ma l'ho visto con i miei occhi e riprodotto almeno 3-4 volte di seguito prima di crederci) e è successo anche se ho sincronizzato esplicitamente tutti i buffer. Concordo con @ jan6352781 sul fatto che sospettassi che fosse dovuto al fatto di non aver completato il processo di scrittura, e lo faccio ancora. In effetti, se aspetti abbastanza a lungo dopo la scrittura prima di riavviare Ubuntu, funziona bene. Non abbiamo motivo di credere che Windows sia in colpa qui, e ogni motivo per credere che Ubuntu lo sia.

— Mehrdad,

7

La riparazione dell'unità non la formatta. Funziona con chkdsk. Non formatta più il disco di quanto fsck formatta un disco.

— Journeyman Geek,

16

L'intera risposta è solo un rant di Windows con zero prove (tranne aneddotiche).

— Millie Smith il

18

Come hai suggerito in un commento, ciò è probabilmente dovuto al fatto che Ubuntu non ha completato il processo di scrittura prima di rimuovere l'unità flash. Ubuntu scrive i file nella RAM durante il processo di copia e scrive questi file dal buffer sull'unità USB in background dopo la chiusura della finestra di dialogo della copia. C'è un'altra rispostaciò suggerisce che ciò è particolarmente un problema per le macchine con grandi quantità di memoria, ma è probabile che tu stia rimuovendo l'unità prima che la scrittura in background sia completa. Quando si espelle un'unità, questo forza la scrittura del buffer sul disco, ma è difficile stabilire quando la scrittura è stata effettivamente completata. C'è un pop-up nelle nuove versioni (15.10 per certo, forse 15.04) destinato a rimediare a questo - un avviso viola appare dopo qualche tempo (generalmente breve) che dice che qualcosa come "[Drive] ora può essere rimosso" una volta la scrittura è terminata.

Questo è probabilmente il motivo per cui il tuo amico ha suggerito la sincronizzazione. L'esecuzione syncnel terminale impone la scrittura su disco di tutti i dati bufferizzati e deve essere restituita solo al termine della scrittura (vedere questa risposta ). Vedi questa risposta per un'utilità che ti aiuterà a determinare se questo è effettivamente il problema.

— alex_d
fonte

Ottengo il popup in 14.04 (edizione Linux Mint KDE) ogni volta che espelle un'unità USB e anche le mie macchine Kubuntu 15.10. Non sono sicuro del 15.04, ma lo suppongo.

— Jon Bentley,

1

La GUI non lo rende davvero ovvio? Sto usando ejectnel terminale da molto tempo, e c'è un notevole ritardo prima che ritorni se ho appena copiato un file di grandi dimensioni.

— Izkata,

1

@Izkata Su Ubuntu 14.04 vaniglia, quando fai clic sul simbolo di espulsione in Nautilus scompare immediatamente. A differenza delle unità interne, tuttavia, le unità USB scompaiono completamente dalla barra laterale quando completamente smontate (ovvero la scrittura è terminata), quindi c'è un certo periodo di tempo durante il quale l'unità USB viene scritta ma sembra essere espulsa.

— alex_d

5

Ho visto un sacco di unità USB, in particolare schede flash (SD, ecc.) Negli adattatori USB, con i file system FAT (praticamente ogni unità USB preformattata con FAT32) si sono corrotte durante l'utilizzo di distribuzioni di Ubuntu e Ubuntu. Era quasi un evento regolare ogni pochi mesi di uso quotidiano regolare.

Se fosse un problema hardware, la formattazione delle partizioni con ext3 (o 4) non dovrebbe aiutare, ma ext3 / 4 rende i filesystem praticamente a prova di proiettile. (ext2 inoltre è stato danneggiato nei pochi mesi in cui l'ho provato; avrebbe dovuto avere meno scritture, quindi una vita più lunga per le unità flash, principalmente da nessun diario).

Quindi, Ubuntu non dovrebbe danneggiare fisicamente le unità USB, ma non mi fido ancora al 100% con i filesystem FAT.

Penso che la corruzione del filesystem possa essere meglio evitata da:

Non scollegare mai un'unità USB fino a quando non è stata smontata / umount/ espulsa. Anche se l'unità non sta scrivendo nulla (se ha una luce non lampeggia) e anche se hai fatto un syncfilesystem potrebbe ancora
Attendere almeno qualche secondo dopo umount/ espellere prima di scollegarlo. Sembra che anche dopo che umountla spia di attività dell'unità possa a volte continuare a lampeggiare per un po '. Altri utenti come questo ragazzo dicono che potrebbe durare fino a un minuto.
Non fare affidamento solo su syncnessuno dei due, come questo tizio che ha subito la corruzione dei file.

Link correlati (generalmente):

— Xen2050
fonte

3

Questo ha poco a che fare con qualsiasi sistema operativo. Si tratta di un errore del file system, che nella maggior parte dei casi indica che l'unità non è stata smontata correttamente (errore utente). Non è un'indicazione assoluta di danno, indica semplicemente una possibilità di un danno. Se presente, il danno è generalmente limitato all'ultimo o agli ultimi file scritti. In questo caso il comando "Ripara" di Windows esegue la scansione dell'unità per settori contrassegnati come "occupati", ma non assegnati a nessun file e quindi assegna questi scarti e pezzi a nuovi file.

Questo errore può essere creato anche su Windows, se si estrae l'unità durante la scrittura senza prima smontarla (in Windows "Espelli" esegue lo smontaggio).

La visualizzazione di questo messaggio indica che l'unità non è stata smontata correttamente.

Puoi verificare da solo se il file system è stato veramente danneggiato o è solo falso positivo: se dopo aver eseguito "Ripara" appare una nuova cartella denominata "found000" con alcuni file, significa che c'era davvero una scrittura incompiuta che è stato interrotto. Alcuni dei tuoi dati sono andati persi e questo è un problema.

— Agent_L
fonte

2

Uso diversi anni Ubuntu e Windows con dual-boot, e quando smonto l'unità nel modo corretto, in Windows visualizzo sempre il messaggio di errore, ma non è mai stato un errore sul mio drive USB. In W10 è possibile disattivare questo messaggio di errore a comparsa.

— tviragh
fonte

1

Non c'è quasi modo per nessun sistema operativo di danneggiare l'unità USB, dopo un formato normale (non rapido), non dovrebbe esserci più traccia che l'unità sia mai stata utilizzata con Ubuntu.

Controllare le unità con "H2testw" o "USB Flash Drive Tester" - i settori danneggiati potrebbero essere fonte di molti strani errori.

— user158037
fonte

4

L'OP è scritto male, ma significa "file system", non "flash ROM".

— wizzwizz4,

Sembra che l'OP possa significare un danno effettivo all'unità USB , dicono "Non ho mai avuto un'unità USB corrotta o danneggiata, ma negli ultimi due anni tre delle mie unità USB sono diventate inattive " Se intendessero semplicemente corrotte, probabilmente avrebbero detto corrotte, invece di "inoperativo" @ wizzwizz4

— Xen2050

3

@ Xen2050 Eppure tutte le altre risposte e i thread dei commenti, incluso jan6352781, implicano o dichiarano che il file system è il problema e il "dispositivo guasto" è un'estrapolazione del loro funzionamento non corretto.

— wizzwizz4,

@ wizzwizz4 Bene, nella risposta di Mark Kirby, l'OP commenta "3. Gli ultimi anni ho saltato la riparazione quasi ogni giorno finendo con file danneggiati e unità USB ." Immagino che sia solo da vecchie unità che avrebbero fallito, Windows o no, ma l'OP lo ha ancora detto

— Xen2050,

@ Xen2050 O forse l'OP si riferiva al vecchio messaggio "Il dispositivo è danneggiato. Vuoi che Windows lo ripari?" (parafrasato) che a volte emerge quando una diversa DLL gestisce il problema. (L'ho fatto apparire io stesso, anche se non sono sicuro che l'ultima frase sia giusta.)

— wizzwizz4

1

Non posso dire se l'unità è stata "danneggiata", forse lo era e forse no. Ma come qualcuno che può dire lo stesso: "Per più di 10 anni lavorando con Windows ...", posso dirti che se stai usando Windows 10 potrebbe essere la fonte dei tuoi nuovi problemi. Ho riscontrato un nuovo problema il mio primo giorno il 10: in 10 viene creato un database per unità esterne (potrebbe essere il database di indicizzazione, non ricordo). Se quel database non corrisponde all'unità, ti dirà che l'unità è danneggiata, a volte puoi ignorare questo avviso e altre volte (vedi aneddoto). L'esecuzione di "riparazione" risolverà il database.

aneddoto:

Non ricordo dove ho trovato queste informazioni ma l'ho scoperto quando ho spostato la mia cartella Music. Si lamentava che l'unità era rotta invece di lamentarsi solo della cartella che cercava non esistesse più. Prima di eseguire la riparazione, la nuova posizione appariva su Ubuntu e la vecchia posizione su Windows 10 ... ma tutti i file non potevano essere aperti su 10. Dopo l'esecuzione della riparazione, la nuova posizione della cartella Music appariva in Windows, la vecchia cartella è scomparso e ha funzionato di nuovo su Windows.

Anche la corsa syncnon è una cattiva idea.

— Nero
fonte