USB-Medien, die während des Schreibvorgangs sicher entfernt werden können

Ich habe mehrere Tests mit dem Entfernen von USB-Medien durchgeführt, während diese beschrieben wurden. Host-System ist Linux Mint 17.1 auf einem Laptop mit USB 2.0. Bei USB - Festplatten scheinen die Daten nach dem Aufrufen von "sync" sicher geschrieben und in keiner Weise verfälscht zu werden, zumindest bei Verwendung von EXT4 mit data=journal Möglichkeit. Das ist in Ordnung für mich, meine Skripte schreiben zuerst in ein temporäres Verzeichnis, rufen dann 'sync' auf und benennen das Verzeichnis dann in seinen endgültigen Namen um (was eine atomare Operation sein sollte).

Meine Tests mit einem USB-Stick waren jedoch weniger überzeugend. Mit den gleichen Skripten und Mount-Optionen bin ich die ganze Zeit auf Korruption gestoßen. Genauer gesagt: Ich benutze 'rsync' mit der --link-dest Option für Backups auf das USB-Medium. Was ich als "Beschädigung" bezeichne, beinhaltet Dateien in einer Sicherung, bei der sich die Daten von der Datei auf dem Hostsystem unterscheiden, die Änderungszeit jedoch nicht. Das ist eine böse Sache seitdem rsync betrachtet diese Dateien als aktuell, wenn sie tatsächlich veraltet sind oder mit Nullbytes gefüllt sind usw.

Frage: Warum passiert das bei USB-Sticks und nicht bei Festplatten? Oder hatte ich bisher nur Glück mit den Festplatten? Wäre es sinnvoll, ein Flash-Laufwerk von einem anderen Hersteller zu kaufen? Das, mit dem ich hier getestet habe, hat übrigens gestern endgültig aufgehört, nachdem ich es im laufenden Betrieb herausgezogen habe. Vielleicht war es nur ein Produkt von schlechter Qualität.

linux usb-storage filesystem-corruption

— Lasse Kliemann
quelle

Vielleicht können Sie Ihren Test mit einem USB wiederholen, der nicht aufhören wird zu arbeiten, vielleicht war es kein qualitativ minderwertiges Produkt, sondern nur ein fehlerhaftes und dasselbe Betriebssystem. Übrigens kann es schädlich sein Hot-Unplug ein HDD Das sollte erfordern, dass die Köpfe geparkt werden, um Beschädigungen zu vermeiden.

— Hastur

Danke, ich habe heute ein neues Flash-Laufwerk bestellt. Über Kopfparken: Ich habe widersprüchliche Informationen dazu gefunden. Einige sagen, dass alle oder die meisten modernen Laufwerke es schaffen, ihre Köpfe zu parken, wenn die Stromversorgung unterbrochen wird. Vielleicht könnte sich jemand dazu äußern?

— Lasse Kliemann

Gern geschehen. (Hoffen wir, dass) Was heute hier geschrieben wird, kann nach einigen Jahren von Menschen mit unterschiedlichem Kenntnisstand wieder gelesen werden. Also lieber vorsichtig sein. BTW Ich habe noch nie irgendwo vorgeschlagen vorgeschlagen Strom abschalten zu einem Gerät mit beweglichen Teilen, während es schreibt . Inzwischen kann ein USB-Stift relativ wenige Schäden verursachen (Verfälschung des Dateisystem mit normalem Betrieb patchbar), sicher kann es zu Datenverlust oder sogar zu deren Verfälschung kommen, stattdessen kann bei einem Gerät mit beweglichen Teilen ein irreversibler Hardwarefehler .

— Hastur

Weitere Informationen zum Parken von Köpfen (nur wenige): Nehmen Sie sich einen Moment Zeit, um im Internet zu lesen Fang hier an . Alt HDD sollten nur in desktop verwendet und wirklich selten bewegt werden. Wenn ich mich richtig erinnere, gab es einen bestimmten Befehl zu physisch park der Kopf. Beachten Sie nicht den Kopf__s__. Heutzutage wird der Parkplatz bewegt, um den Kopf weiter zu bewegen Landezone wo keine Daten gespeichert sind.

— Hastur

Nach dem Testen mit dem neuen Flash-Laufwerk hat sich herausgestellt, dass alle Probleme darauf zurückzuführen sind, dass das vorherige Flash-Laufwerk defekt war oder eine schlechte Qualität aufwies. Mit dem neuen Flash-Laufwerk und auch den Festplatten konnte ich keine Beschädigung feststellen, indem ich das Laufwerk während des Schreibvorgangs aus der Steckdose zog. Ich habe sogar die Mount-Optionen durch Weglassen gelockert data=journal. Meine Mount-Optionen sind jetzt insgesamt rw,noatime,errors=remount-ro und ich benutze EXT4.

In Bezug auf andere Dateisysteme verhält sich XFS nach meiner Erfahrung mit Linux Mint 17.1 schlecht, wenn es im laufenden Betrieb entfernt wird, und hinterlässt häufig einen nicht entfernbaren Mount, für den ein Neustart erforderlich ist. JFS ist in dieser Hinsicht in Ordnung, aber erstaunlich langsam, für bestimmte Operationen fast unbrauchbar. BTRFS sieht gut aus, aber Mint kommt mit einer veralteten und immer noch instabilen Version, also habe ich mich dagegen entschieden. Ebenso werden NILFS2 und F2FS derzeit von Mint nicht gut unterstützt.

Ein Wort der Warnung: Obwohl ich durch Hot-Unplugging keine Beschädigung verursachen konnte, liegt es immer noch in der Verantwortung des Benutzers, die Puffer zu leeren, bevor eine Datei an ihrem endgültigen Speicherort abgelegt wird. Ein Sicherungsprogramm muss also zuerst an einen temporären Speicherort kopiert und dann aufgerufen werden syncund benennen Sie dann die Datei oder das Verzeichnis in den endgültigen Namen um (unter dem in Zukunft eine vollständige Kopie erwartet wird).

— Lasse Kliemann
quelle