Vielleicht bin ich hier falsch …
Vermutung: Diese Begriffe sind auch für USB-Sticks, überhaupt für alle Flashspeichermedien relevant. (Auch in der Wikipedia wird merkwürdigerweise für das Defektmanagement allgemein in Flash-Speichern auf Wear leveling im Artikel über SSDs verwiesen.)
Ich komme jetzt zwar mit einem persönlichen Problem, das hat aber vielleicht allgemeine Bedeutung und sollte irgendwo in diesem Wiki beschrieben werden (hier auf der Seite „auch andere …“ ergänzen, oder Hinweis in dd/Live-USB, s. u.). Persönliche Situation: So seit April 2013 arbeite ich mit persistenten Live-Installationen auf USB-Sticks. Diese kommen dabei leicht in Schwierigkeiten, und von mindestens sieben USB-Sticks habe bislang festgestellt, dass sich die Partitionstabelle mit fdisk, GNU parted und GParted nicht mehr ändern ließ, „Eingabe-/Ausgabefehler“, auch „das Dateisystem ist nur lesbar“. Im laufenden Jahr war es weniger schlimm, vielleicht weil ich hauptsächlich mit einem Stick gearbeitet habe, der keine Schwierigkeiten machte, (SanDisk Cruzer Fit, den kann ich beim Verpacken des Notebooks im Suspend to RAM steckenlassen, Suspend to RAM ist für mich sehr wichtig, weil Neustarts – außer mit dem Fit – recht lange dauern und ich mit Lubuntu meine 5 oder mehr Standardtabs in LXTerminal immer von Hand neu einrichten muss). Das finale Erlebnis hatte ich aber doch mindestens zwei Mal, zuletzt am Montag.
Für wesentlich halte ich, dass sich das Problem nicht auf Live-Installationen in Gebrauch beschränkt, das ist mir vielmehr auch in folgenden Fällen passiert:
Ich wollte eine mehr als 8GB große Datei auf einem 16GB-Stick speichern und lernte, dass das mit FAT32 (wie gekauft) nicht geht. Beim Umformatieren auf Linux (ext) gab es Schwierigkeiten, und das Ergebnis einer gründlichen badblocks-Untersuchung (d. h., mit Schreibtests) war eben das „finale“.
Ich hatte eine Festinstallation auf USB-Stick eingerichtet (funktionierte auch schon), dann SSD/Alignment beachtet, war nicht ausgerichtet, ich habe (mindestens) eine Partition mit GParted zwecks Ausrichtung verschoben – Ende.
(Ich glaube, zweimal passiert:) Einrichtung mit USB Creator: meldet irgendeinen Fehler, oder bricht ab, weder mit Erfolgs- noch Fehlermeldung (manchmal war in solchen Fällen die Installation anschließend völlig in Ordnung) – Ende. Das haben auch zwei Nutzer in irgendeinem Ubuntu-Forum berichtet.
Insgesamt steht das in auffälligem Gegensatz zur angeblich praktisch unbegrenzten Lebensdauer von SSDs. Außerdem handelte es sich um Fabrikate von vier unterschiedlichen Herstellern, und bei Intenso sowohl um die neuere Alu Line als auch um die ältere Rainbow Line (dieser Stick hatte mir vor seiner Live-Nutzung zwei Jahre als reine Sicherung gedient). So habe ich nun doch wieder mal nach derartigen Erlebnissen gegoogelt. In einem Beitrag fand ich ungefähr folgende
Idee: Wenn die Partionstabelle nicht mehr änderbar ist, ist das kaum ein physikalischer oder anderer Defekt des Flashlaufwerks, sondern Symptom davon, dass aus Sicht der Wear-Leveling-Firmware des Laufwerks alle Speicherzellen mit Daten belegt sind.
Konkret könnte das so passieren (das stelle ich zur Diskussion; vgl. obige Sonderfälle):
(a) Man „nullt“ (dd) den gesamten Stick, weil in manchen Foren steht, dass dadurch irgendwelche „Irritationen“ aus dem alten Laufwerksinhalt, die vielleicht das Formatieren/Partitionieren behindern, beseitigt würden (ist vielleicht OK für HDDs). Danach ist der Stick aus Firmware-Sicht voll mit „Daten“ belegt.
(b) Man führt badblocks mit Schreibtests auf dem gesamten Stick aus (s. o.). Danach ist der Stick aus Firmware-Sicht komplett mit „Daten“ belegt. – könnte auch mit Option cc mit fsck und mkfs passieren.
(c) Man benutzt dd und dann, wie dort beschrieben, um eine dysfunktional gewordene casper-rw-Partition mittels dd durch ein früheres Abbild zu ersetzen (das habe ich tatsächlich vor zwei Wochen mit dem Stick getan, der diese Woche in den „finalen Zustand“ geriet). Die Partition hat 1,5GB oder viel mehr, wovon aber nur 2/3 oder so mit Daten belegt sind. Aus der Sicht der Firmware ist nun aber auch das restliche Drittel bzw. die ganze Partition mit „Daten“ belegt, insgesamt jedenfalls ein beträchtlicher Anteil der Gesamtkapazität, der aus Nutzersicht eigentlich „frei“/verfügbar ist, zehrt an der Spare Area.
(d) Nach der Anweisung von http://rudd-o.com/linux-and-free-software/a-better-way-to-create-a-customized-ubuntu-live-usb-drive erzeugt man eine casper-rw-Datei in der ersten Partition durch Nullen mit dd. Aus Nutzersicht ist die zuerst einmal leer, die Stick-Firmware betrachtet aber alle entsprechenden Speicherzellen als belegt. – Auch der USB Creator verwendet casper-rw als Datei in der ersten Partition, vielleicht auch durch Nullen? Es dauert jedenfalls ähnlich lange. Im weiteren frage ich mich dann, was casper mit dieser Datei beim Runterfahren macht und was die Stick-Firmware daraus schließt.
(e) Das Verschieben einer Partition mit GParted (s. o.) dauert so lange, dass ich annehme, dass dabei sämtliche zur Partition gehörige Adressinhalte umkopiert werden, auch wenn die Partition aus Nutzersicht noch kaum „Daten“ enthält, Effekt wie (d). – So, das war's.
Fragen: Kann das sein? Müsste man in solchen Fällen immer mit einem fstrim von Hand nacharbeiten? Oder sollte man einfach überhaupt nicht mit dd auf Flash-Medien schreiben (außer wenn das Abbild sowieso nicht mehr geändert werden soll, wie dd#Live-USB)?
Thanks, Uwe.
Bearbeitet von Justin Time:
Bitte verwende in Zukunft Absätze, Auflistungen, um die Übersicht im Forum zu verbessern und bitte verzichte auf überflüssige Hervorhebungen!
Moderiert von tomtomtom:
Von diesem Thread abgetrennt und ins am wenigsten unpassende Forum verschoben. Themenentführung verstößt gegen den Verhaltenskodex.