Hallo, in welchem Moment löscht ein USB-Stick einen Flash-Sektor, bzw. eine Flash-Zelle? Tut er das nach Bedarf in dem Moment, in dem er einen Schreibbefehl für einen Sektor erhält erhält (mit der typischen Folge einer verlangsamten Schreibrate) oder empfängt ein USB-Stick ähnlich einer 2,5''-SSD TRIM-Befehle und löscht entsprechend ungenutzte Flash-Zellen im Voraus, so dass er bei Erhalt eines Sektorschreibbefehls ohne Löschverzögerung gleich losschreiben kann?
:
Bearbeitet durch User
> in welchem Moment löscht ein USB-Stick einen Flash-Sektor, bzw. eine > Flash-Zelle? Da kocht jeder Hersteller sein eigenes Süppchen. Btw, TRIM dient erstmal der Erhöhung der Lebensdauer (besseres Wear-leveling). Es kann unter bestimmten Bedingungen zu verbesserten Schreibraten führen, zwingend ist das aber keinesfalls (sieh es eher als Ausnahme).
Peter M. schrieb: > Hallo, > > in welchem Moment löscht ein USB-Stick einen Flash-Sektor, bzw. eine > Flash-Zelle? > > Tut er das nach Bedarf in dem Moment, in dem er einen Schreibbefehl für > einen Sektor erhält erhält Gibt es einen solchen "hart addressierten" (Sektor)-Befehl an den externen Speicher überhaupt? Oder kann der Stick resp. der Flashcontroller auf dem Stick selbst entscheiden, wohin er nun die Daten auf den Flash schreibt?! Der PC schickt halt nur ein File/Datenstrom und es ist dem Filesystem auf dem Stick überlassen ob er das in die bereits gelöschte Blöcke/Sektoren schreibt (write) oder erst Blöcke löschen (erase) muß, bevor er diese beschreiben kann. Sinnvoll wäre ein Löschen im Hintergrund, also immer wenn nichts an der USB-Schnittstelle passiert. Deshalb sollte man ja auch nie einen Stick abziehem ohne ihn vorher abzumelden.
Peter M. schrieb: > oder empfängt ein USB-Stick ähnlich einer 2,5''-SSD TRIM-Befehle Ein Stick kann dem OS durchaus mitteilen das die Trim Befehle unterstützt werden, und Windows kann diese auch nutzen. Die Sache ist für den Flash selbst betrachtet komplizierter, da zwischen den Daten auf den Chips und dem USB Port noch ein Controler hängt der nicht-triviale Dinge tut, u.a. Wear Leveling. Daher ist OPs Frage nicht soo einfach zu beantworten. Für kurze Schreibzugriffe muss der Stick nicht unbedingt jedesmal eine Löschaktion starten, denn er hat normalerweise ein paar vorher gelöschte Pages als Puffer zur Verfügung. Man müsste also OP die Frage stellen wieso er das so genau wissen will.
Klaus K. schrieb: > Der PC schickt halt nur ein File/Datenstrom und es ist dem Filesystem > auf dem Stick überlasse Das Filesystem ist bei USB-MSC Geräten auf dem Host implementiert. Das Gerät sieht nur Sektoradressen, genau wie eine klassische Festplatte. Sonst könnte man Sticks ja auch gar nicht mit unterschiedlichen Dateisystemen formatieren. Der Flash-Controller im Stick wird diese Adressen noch einmal auf physische Adressen mappen um Wear Leveling zu ermöglichen. Bei MTP-Geräten ist das anders, aber m.W. gibt es keine Speichersticks die das umsetzen. Dort werden abstrakte Dateizugriffe per USB übertragen, und das Dateisystem ist auf dem Gerät implementiert. Das wird u.a. von Android-Geräten genutzt, weil es auch den gleichzeitigen Schreibzugriff auf Dateien durch das Gerät selber ermöglicht.
Peter M. schrieb: > in welchem Moment löscht ein USB-Stick einen Flash-Sektor, bzw. eine > Flash-Zelle? In dem Moment, wo der Controller des USB-Sticks das Löschkommando an seinen Flash-Chip sendet. Dieser Moment hat allerdings gar nichts damit zu tun, wann du etwas per USB-Kommando an den Stick sendest. Dazwischen sitzt dessen Housekeeping und das Wearleveling und der Cache. Lies mal, was so ein USB-Flash-Controller heute alles kann und macht: - https://www.hyperstone.com/de/USB-31-Controller-Flash-Memory-Controller-2130.html Da wird schnell klar: du greifst mit keinem USB-Befehl jemals irgendwie direkt auf das Flash zu.
:
Bearbeitet durch Moderator
Peter M. schrieb: > oder empfängt ein USB-Stick ähnlich einer 2,5''-SSD TRIM-Befehle Ich habe das mit sieben verschiedenen USB-Flash-Sticks versucht. Nicht ein einziger davon hat TRIM unterstützt. Sandisk, Intenso, Samsung, Transcend, …
Peter M. schrieb: > in welchem Moment löscht ein USB-Stick einen Flash-Sektor, bzw. eine > Flash-Zelle? In dem Moment, wo eine Schreibanforderung erfolgt. Ein fabrikneuer USB-Stick hat also erstmal die doppelte Schreibrate, da alles gelöscht ist. Im Gegensatz zu SSDs kennt ein Stick kein Trim, kann also nicht vorausschauend löschen. Bessere Sticks geben eine kleinere Kapazität an, als an Flash verfügbar ist. Sie haben dadurch einen Pool an nicht zugewiesenen Pages, die sie im Hintergrund löschen können. Z.B. gibt es Sticks mit 256GB (langsam) oder 240GB (schnell).
Peter D. schrieb: > Peter M. schrieb: >> in welchem Moment löscht ein USB-Stick einen Flash-Sektor, bzw. eine >> Flash-Zelle? > In dem Moment, wo eine Schreibanforderung erfolgt. Nein, die werden unabhängig davon beim Garbage Colletion gelöscht und fürs Schreiben vorbereitet. Wenn eine Datei überschrieben oder gelöscht wird, dann wird einfach der Block als "noch zu löschen" markiert und später aufgeräumt. Deshalb ist so ein Stick auch noch einige Zeit nsch Abschluss einer Dateioperation aktiv. Und er wird nach Anlegen einer Versorgung auch einfach so von sich aus aktiv, kontrolliert Referenzzellen und kopiert Blöcke um, wenn sich die Referenzzellen entladen haben und die Daten gefährdet sind.
Hallo Jim M., Jim M. schrieb: > Man müsste also OP die Frage stellen wieso er das so genau wissen will. Es geht darum, zu erkennen, ob eine dateisignaturorientierte Datenrettungssoftware bestimmte komprimierte Dateien erkennt. Ein Datenträger, der TRIM versteht und umsetzt, zerstört die Wiederherstellungsgrundlage und ist für einen solchen Test nicht geeignet.
Lothar M. schrieb: > Wenn eine Datei überschrieben oder gelöscht wird, dann wird einfach der > Block als "noch zu löschen" markiert und später aufgeräumt. Ohne TRIM weiss der Stick bloss gar nichts davon, dass etwas gelöscht wurde, das ist im einfachsten Fall nur ein Schreibzugriff auf einen Sektor, um den Eintrag aus dem Directory (dessen Struktur der Stick nicht kennt) zu entfernen. Insofern können eigentlich nur bisher nicht beschriebene oder Reservesektoren auf Verdacht gelöscht werden. Mit TRIM wäre es anders, aber Norberts Testergebnisse klingen danach, dass das höchstens in seltenen Fällen unterstützt wird. Peter M. schrieb: > Ein Datenträger, der TRIM versteht und umsetzt, zerstört die > Wiederherstellungsgrundlage und ist für einen solchen Test nicht > geeignet. Wenn es rein um Tests geht, kannst Du dafür je nach Betriebssystem auch TRIM sicherheitshalber deaktivieren.
Hmmm schrieb: > den Eintrag aus dem Directory (dessen Struktur der Stick nicht kennt) Du wirst dich wundern, was der Controller da durchaus mitanalysiert. Meine Erfahrung: letzlich ist es die Firmware im Flashcontroller, die einen USB-Stick gut oder schlecht macht. Ich konnte diese Erfahrung mit der Firmware wiederholt(!) bei Xmore microSD-Karten machen: - https://www.mikrocontroller.net/search?query=xmore&forums%5B%5D=1&forums%5B%5D=14&max_age=-&sort_by_date=1 Und darunter besonders den Beitrag "Re: Raspberry Pi langlebigere SD-Karte, wie?" und die Links darin. Der Dauertest mit solchen microSD-Karten läuft übrigens immer noch. Und aus einem Fehler heraus bekam ich zwischendurch mit der "anderen" Firmware programmierte mciroSD --> die Karten waren nach 2 Wochen kaputt. Mit der "richtigen" Firmware halten die selben im Dauertest jetzt inzwischen gut 9 Monate. Also macht die Firmware mindestens den Faktor 80 in der Lebensdauer aus.
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Ich konnte diese Erfahrung mit der Firmware wiederholt(!) bei Xmore > microSD-Karten machen: Bei SD-Karten gibt aber die Spec das FAT Dateisystem vor, bei USB-Sticks nicht.
Beitrag #7552010 wurde vom Autor gelöscht.
Niklas G. schrieb: > Bei SD-Karten gibt aber die Spec das FAT Dateisystem vor So ganz eineindeutig ist das da aber nicht festgelegt und vor allem: die Karte verhindert nicht, dass du ein anderes FS verwendest. Ich habe eine steinalte Kamera, die formatiert jede SD-Karte ungefragt auf FAT16 um. > bei USB-Sticks nicht. Allerdings kann ich mit überaus hoher Wahrscheinlichkeit vorhersagen, dass ich heute exFAT (oder ausnahmsweise noch FAT32 bzw. NTFS) auf dem Stick antreffen werde. Und dann ist es nachvollziehbar, dass die Hersteller für solche FS mit einer Verbreitung >99% irgendwelche Optimierungen einbauen.
Lothar M. schrieb: > Du wirst dich wundern, was der Controller da durchaus mitanalysiert. > Meine Erfahrung: letzlich ist es die Firmware im Flashcontroller, die > einen USB-Stick gut oder schlecht macht. Es wäre aber schon recht merkwürdig, wenn ein Hersteller diesen Aufwand treibt und dann diese Zusatzfunktionen nicht extra bewirbt. Insbesondere wäre es sinnvoll, die analysierten FS auch zu benennen. Auch muß sicher verhindert werden, daß fälschlich Daten gelöscht werden. Z.B. wenn der Stick als linearer Speicher ohne bekanntes FS für Datenlogger verwendet wird.
Hab' hier gerade einen 128GB: ›Bus 003 Device 002: ID 0781:5583 SanDisk Corp. Ultra Fit‹ der seltsame Symptome zeigt. Da kein TRIM funktioniert, läuft nun testweise eine Routine welche den Stick im Zeitlupentempo mit 0x00 füllt. Immer alle zwei Sekunden einen kompletten 2MiB Block. Mal sehen ob der Controller diese ›leeren‹ Blöcke löscht und intern als frei markiert. Sollte sich dann später in der Schreibgeschwindigkeit zeigen. Werde demnächst berichten… Wer's versuchen will:
1 | pv -L 1M </dev/zero \ |
2 | | dd if=/dev/stdin of=/dev/sdX \ |
3 | iflag=fullblock bs=2M |
:
Bearbeitet durch User
Lothar M. schrieb: > Niklas G. schrieb: >> Bei SD-Karten gibt aber die Spec das FAT Dateisystem vor > So ganz eineindeutig ist das da aber nicht festgelegt und vor allem: die > Karte verhindert nicht, dass du ein anderes FS verwendest. Ich habe eine > steinalte Kamera, die formatiert jede SD-Karte ungefragt auf FAT16 um. O doch, das ist eindeutig festgelegt. SD(SC)-Karten (mit bis zu 2 GByte Größe) müssen mit FAT16 formatiert werden, SDHC-Karten (zwischen 4 und 32 GByte Größe) müssen mit FAT32 formatiert werden und SDXC-Karten (zwischen 64 GByte und 2 TByte Größe) sowie SDUC-Karten (größer als 2 TByte) sind mit exFAT zu formatieren. Das steht so in der Spezifikation. Insofern verhält sich Deine steinalte Kamera korrekt, es sei denn, die macht das auch mit SDHC-Karten. Es gab mal nichtstandardkonforme SD-Karten, das waren SDSC-Karten mit mehr als 2 GByte Kapazität. Sowas funktionierte nur in bestimmten Fällen.
Harald K. schrieb: > SD(SC)-Karten (mit bis zu 2 GByte Größe) müssen mit FAT16 formatiert > werden, SDHC-Karten (zwischen 4 und 32 GByte Größe) müssen mit FAT32 > formatiert werden Auch wenn ich da 2 Partitionen mit 2G drauf mache? > Das steht so in der Spezifikation. > Insofern verhält sich Deine steinalte Kamera korrekt, > es sei denn, die macht das auch mit SDHC-Karten. Ja, das war mit "jede SD-Karte" gemeint. Die Kamera kann das mit den SDHC aufwärts gar nicht wissen, sie ist zu alt dafür. Harald K. schrieb: > SD(SC)-Karten (mit bis zu 2 GByte Größe) müssen mit FAT16 formatiert > werden, SDHC-Karten (zwischen 4 und 32 GByte Größe) müssen mit FAT32 > formatiert werden Nein, sie sollen damit formatiert werden, damit sie sich so verhalten, wie es den geschriebenen Worten entspricht. Sie verhindern aber nicht, dass ich es anders mache. Samsung formuliert das dann dementsprechend vorsichtig und benennt ein "standardmäßig verwendetes Dateisystem": - https://www.samsung.com/de/support/memory-storage/was-bedeuten-die-angaben-sd-sdhc-sdxc-auf-meiner-sd-karte-bzw-microsd-karte/
Lothar M. schrieb: > Auch wenn ich da 2 Partitionen mit 2G drauf mache? Das erlaubt die Spec nicht. Es gehört genau 1 Partition mit einer ganz bestimmten Aufteilung drauf mit dem jeweiligen FAT-System. Lothar M. schrieb: > Sie verhindern aber nicht, > dass ich es anders mache. Sie könnten es, und wären dennoch spezifikationskonform.
Lothar M. schrieb: > Auch wenn ich da 2 Partitionen mit 2G drauf mache? Dann verletzt Du die Spezifikation, die das nicht vorsieht. Das heißt nicht, daß die Karte dann nicht funktioniert, sondern nur, daß Du Dich dann halt nicht an die Spezifikation hältst und Deine so formatierte Karte nicht in Geräten funktionieren wird, die sich wiederum an die Spezifikation halten. Lothar M. schrieb: > Ja, das war mit "jede SD-Karte" gemeint. Die Kamera kann das mit den > SDHC aufwärts gar nicht wissen, sie ist zu alt dafür. Sie sollte eigentlich SDHC-Karten gar nicht erst beschreiben (oder auch nur lesen) können, weil die ein geändertes Protokoll verwenden. Lothar M. schrieb: > Sie verhindern aber nicht, dass ich es anders mache. Natürlich nicht. Nur kannst Du dann halt nicht erwarten, daß die Karte in einem Gerät funktioniert, das entsprechende Karten erwartet. Eine mit extfs formatierte Karte wird in einer Digitalkamera nur Schulterzucken erzeugen, während der Raspberry Pi davon booten kann.
Niklas G. schrieb: > Das erlaubt die Spec nicht. Wie gesagt: auch das interessiert die Karte nicht. Ich habe viele Karten vieler Hersteller mit 2 Partitionen versehen (eine davon ist versteckt und enthält den Bootloader für den Rechner) und alle haben klaglos mitgespielt. Das meint die Windows Powershell mit get-partition dazu:
1 | PartitionNumber DriveLetter Offset Size Type |
2 | --------------- ----------- ------ ---- ---- |
3 | 1 D 100663296 3.61 GB FAT32 |
4 | 2 3971743744 1 MB Unknown |
Lothar M. schrieb: > Peter D. schrieb: >> Peter M. schrieb: >>> in welchem Moment löscht ein USB-Stick einen Flash-Sektor, bzw. eine >>> Flash-Zelle? >> In dem Moment, wo eine Schreibanforderung erfolgt. > Nein, die werden unabhängig davon beim Garbage Colletion gelöscht und > fürs Schreiben vorbereitet. Wenn eine Datei überschrieben oder gelöscht > wird, dann wird einfach der Block als "noch zu löschen" markiert und > später aufgeräumt. Das ginge aber nur mit TRIM, denn es gibt auf der USB-Seite nur lesen und schreiben, kein löschen. Woher soll der Stick also wissen, in welchen Sektoren die Daten als "gelöscht" gelten können und welche noch benötigt werden? > Deshalb ist so ein Stick auch noch einige Zeit nsch Abschluss einer > Dateioperation aktiv. Das liegt eher am Betriebssystem-Cache, der noch vollends auf den Stick geschrieben werden muss. Harald K. schrieb: > Lothar M. schrieb: >> Niklas G. schrieb: >>> Bei SD-Karten gibt aber die Spec das FAT Dateisystem vor >> So ganz eineindeutig ist das da aber nicht festgelegt und vor allem: die >> Karte verhindert nicht, dass du ein anderes FS verwendest. Ich habe eine >> steinalte Kamera, die formatiert jede SD-Karte ungefragt auf FAT16 um. > > O doch, das ist eindeutig festgelegt. Es gibt ja auch von der SD Association einen speziellen Formatter, der die Karte genau nach Spec partitioniert und formatiert. Bei Geräten wie Kameras sollte deren Firmware das auch einhalten, wenn man die Karte dort formatiert. Lothar M. schrieb: > Niklas G. schrieb: >> Das erlaubt die Spec nicht. > Wie gesagt: auch das interessiert die Karte nicht. Der Controller der Karte kann durchaus von der Annahme ausgehen, dass sie nach Spec formatiert und partitioniert ist. Kommt also drauf an. Bei FAT gibt es ja Sektoren, die bei jedem Schreibvorgang auch mit beschrieben werden müssen. Die Karte kann z.B. Vorkehrungen haben, damit genau diese Sektoren besonders ausdauernd sind, was dann nicht mehr funktioniert, wenn du die Karte anders partitionierst und die Sektoren dadurch an einer anderen Stelle zu liegen kommen.
Lothar M. schrieb: > Wie gesagt: auch das interessiert die Karte nicht. Unterscheide doch bitte mal was die Spec verlangt und was die Hersteller einer bestimmten Karte implementieren. Die Spec definiert im Wesentlichen ein Interface. Das Interface verlangt vom Host, die Karten mit genau einem FAT der jeweiligen Sorte zu formatieren und zu verwenden, und von der Karte, das korrekt zu unterstützen. Die Karte kann als "Erweiterung" auch andere Partitionen/Dateisystem unterstützen, muss sie aber nicht. Ein Gerät (z.B. Kamera) muss das FAT unterstützen, um standardkonforme Karten nutzen zu können. Die Kamera kann auch EXT2 unterstützen, braucht sie aber nicht. Ein Gerät welches FAT nicht unterstützt, ist nicht spec-konform, kann aber mit bestimmten Karten trotzdem funktionieren. Ist wie bei der Programmiersprache C: Der Compiler/Library muss Standardfeatures wie z.B. "static" oder "printf" unterstützen. Er kann auch Erweiterungen wie "__asm__" oder "__flash" unterstützen, muss er aber nicht. Nur weil "__flash" mit einem Compiler funktioniert, muss es nicht mit allen Compilern funktionieren. Jeder Compiler muss alle Programme, welche ausschließlich Standard-Features nutzen, korrekt übersetzen. Ein Programm welches Nicht-Standard-Features benötigt kann mit bestimmten Compilern funktionieren, aber nicht notwendigerweise mit allen.
:
Bearbeitet durch User
Harald K. schrieb: > SD(SC)-Karten (mit bis zu 2 GByte Größe) müssen mit FAT16 formatiert > werden, SDHC-Karten (zwischen 4 und 32 GByte Größe) müssen mit FAT32 > formatiert werden und SDXC-Karten (zwischen 64 GByte und 2 TByte Größe) > sowie SDUC-Karten (größer als 2 TByte) sind mit exFAT zu formatieren. Und was hat das nun mit USB-Sticks zu tun? Bleibt dochmal beim Thema und macht für eine anderes Thema auch einen neuen Thread auf. Sonst reden hier alle nur durcheinander.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.