zuverlässige SD-Karte für Raspberry Pi

Boote von SD un pack das gesamte root-FS auf eine USB-Disk!
Dann reicht die kleinste Speicherkarte die du finden kannst, und auf der 
Karte wird im Normalfall niemals geschrieben.

Ich hatte bisher keine Probleme mit SD-Karten im RPi, auch Noname-Karten 
funktionieren.

Aus dem Foto- und Smartphone-Bereich habe ich aber mittlerweile diese 
Erkenntnisse gewonnen: Finger weg von SanDisk (langsam beim Schreiben, 
Datenverlust nach dem "Auswurf" am Tablet). Die Evo- und Pro-Modelle mit 
dem plus-Zusatz von Samsung sind zwar teurer aber sauschnell und 
zuverlässig.

Nun jeder hat andere Erfahrungen mit Speicherkarten gemacht.
Ich hab bislang welche von Sandisk und Transcend und bislang ist nach ~ 
10 Jahren eine nun Kaputt gegangen mit "Sektorenfehler" von der Digicam.
Hab da ein anderen PI wo eine Sandisk 4 GB drin ist der seit >1 Jahr im 
Dauerbetrieb läuft und keine Probleme macht.

Aber wenn du auf Veranstaltung/Mobil ist wäre ggfs ein Banana Pi besser 
mit Sata Anschluss wo du eine SSD Verwendest.
Beim Banana Pi hast du Modelle wo der Sata Port nicht wie beim Raspberry 
über USB Angebunden ist wodurch du nochmal etwas mehr Geschwindigkeit 
hast.

Was aber meist der Fehler ist, ist durch den Transport die 
Speicherkarte/Stecker sich Lösen und so Kontaktprobleme entstehen.

Wenn du es Sicher haben möchtest wäre ein zweiter schon gut als Online 
Spiegelung bzw ein zweiten Pi mit Speicherkarte der Startbereit ist und 
ein ext USB Stick wo die Daten extra nochmal gespeichert werden und du 
nur umstecken brauchst.

@c-hater:
Hast du dazu auch eine echte Quelle?
Ja, man findet ein paar Hände voll Berichten im Netz dass SD-Karten bei 
Nutzung in Raspi korumpiert wurden, aber das hält sich in grenzen. Zudem 
scheint die Ursache meistens ein Powerloss während dem Schreibvorgang zu 
sein (also Abstecken vom Strom während geschrieben wird).

Du machst dem TE grad unnötig ziemliche Angst >_>
Er ist nicht der einzige der einen Raspberry für Echtzeit-Protokolierung 
von irgendwas nutzt. Das ist sogar eine der häufigsten 
Verwendungsmöglichkeiten des Raspberrys.


@Phil:
Das Ganze wird nicht physisch belastet, oder? Also der Raspberry wird 
nicht ständig bewegt o.ä.?
Dann ist die Ausfallwahrscheinlichkeit grad während der Nutzungsperiode 
schon sehr gering.

Weitreichende Statistiken welche SD-Karte im Raspberry am längsten lebt 
gibt es meines Wissens nach nicht - wohl einfach weil sie zu selten 
kaputt gehen.
Allgemein kann man aber sicherlich empfehlen, nicht die günstigste zu 
nehmen und zumindest intuitiv würde ich schätzen, dass schnellere Karten 
auch robuster sein müssten (wahrscheinlich ist das aber ein Trugschluss, 
da wie schon erwähnt wurde, nicht das standardmäßige Dateisystem 
Verwendung findet).

EDIT:
Wenn du dir wirklich Gedanken machst, kannst du mal nach einer "SLC SD 
Card" suchen. Die sind technisch bedingt robuster (im Endefekt heisst 
dies dass sich eine 1 und eine 0, physikalisch mehr voneinander 
unterscheiden). Das ist wohl die Hauptdiferenz zu den "Consumer Karten" 
denn in Sachen Featurelevel ist inzwischen der Consumer Bereich auf dem 
selben Niveau.

Ob sich das wirklich lohnt?
Würde ich persönlich eher verneinen...
Dann doch eher versuchen eine echte Redundanz zu schaffen. Statistisch 
ist  menschliches Versagen (jemand kommt ans Kabel) ziemlich sicher 
wahrscheinlicher als der eigenständige Ausfall :D

EDIT 2: Hier eine Suche: 
http://www.mouser.de/Semiconductors/Integrated-Circuits-ICs/Memory-Storage/Memory-Modules/Memory-Cards/_/N-9x4ns?P=1yy7k55Z1z0w1t4Z1yxxwsy
Wobei ich leider nicht weiss was Panasonic wohl mit "SLC Lite" meint.

Steffen schrieb:
> Und ein USB Stick ist besser als eine SD-Karte oder denkst Du an eine
> richtige Festplatte?

Ich meine eine richtige Festplatte

Kai A. schrieb:
> Nun jeder hat andere Erfahrungen mit Speicherkarten gemacht.
Ich habe von meinen mal im 
Beitrag "Re: MIcroSD Karte durch Raspberry PI zerstört" berichtet.

Alex G. schrieb:
> Das ist wohl die Hauptdiferenz zu den "Consumer Karten" denn in Sachen
> Featurelevel ist inzwischen der Consumer Bereich auf dem selben Niveau.
Ich habe vorrangig die Erfahrung gemacht, dass eine gute Firmware den 
größten Effekt bringt.
So waren die ersten Xmore-Karten, die als "industrietauglich" beworben 
wurden, schon nach 3-7 Tagen im Dauerschreibtest kaputt. Nach einer 
Reklamation wurde das Fehlerbild untersucht, die Firmware der Karten 
geändert (dass überhaupt jemand reagiert und was gemacht hat, war für 
mich ein ganz neues Erlebnis, andere Hersteller zeigten dort absolut 
keine Reaktion) und neue Muster beigestellt, die dann über ein 
dreiviertel Jahr liefen.
Fazit:
gleiche Hardware, andere Software --> Lebensdauer hundert mal größer.

> Wenn du dir wirklich Gedanken machst, kannst du mal nach einer "SLC SD
> Card" suchen.
Ich habe hier teuere SLC "Industriequalitätskarten", die nach 2 Wochen 
Dauerbeschreiben schon kaputt sind.
Wie gesagt: die Xmore "pseudoSLC" mit der richtigen Firmware halten ein 
dreiviertel Jahr. Samsung und Toshiba Consumer-TLC-Karten sind nicht 
viel schlechter...

Dieser Dauerschreibtest läuft nun mit unterschiedlichen Karten seit ca. 
3 Jahren und er wird auch die nächsten Jahre noch weiterlaufen. Derzeit 
sind gerade wieder Xmore-Karten drin, da dauert es aus obigen Gründen 
länger, als wenn die Karten nach 4 Wochen schon den Geist aufgeben.

Ja, wie wichtig Firmware ist, hat man durchaus schon bei SSDs sehr gut 
gesehen. "Wear-Leveling" und "Write Amplification" sind da gute 
Stichworte.
Nur ist grade software etwas was man mit relativ geringem Aufwand, bzw. 
kaum Zusatzkosten, dann schnell auch in die Consumer Produkte bringen 
kann.
Die paar Artikel die "Industrie SD Karten" anpreisen, die ich gefunden 
hab, sind inzwischen 5 Jahre oder älter.

Deine Statistik ist in der tat interessant!

Alex G. schrieb:
> Nur ist grade software etwas was man mit relativ geringem Aufwand, bzw.
> kaum Zusatzkosten, dann schnell auch in die Consumer Produkte bringen kann.
Allerdings kostet eben gute Software auch Geld und Zeit. Das erstere 
wäre nicht so schlimm, aber kein Hersteller wartet heute, bis die 
Software "fertig" und ausgereift ist...

Logisch. Ich ging nur davon aus dass der Hersteller eben bereits 
"Industrie Karten" mit der Firmware im Angebot hat.

Btw. grad gemerkt in meinen 2 Raspis hab ich "Toschiba Exercia" Karten 
drin. Allerdings nutze ich die nicht in ausgiebigem Stil.

c-hater schrieb:
> ICH bin hier die "echte Quelle".
Ich sehe da keine verlässliche oder gar brauchbare Quelle sondern 
nur persönliche Erfahrungen und Vermutungen. So wie meine Dauermessungen 
an microSD Karten eben auch Erfahrungen und Vermutungen produzieren.
Eine "echte Quelle" wäre für mich einer, der Einsicht in die Hard- und 
Firmware von SD-Karten hat.

Alex G. schrieb:
> Wobei ich leider nicht weiss was Panasonic wohl mit "SLC Lite" meint.
Das ist das selbe wie pseudoSLC: eine MLC-Zelle wird statt mit 2 Bits 
nut mit 1 Bit beschrieben und ist damit in etwa so wie eine SLC-Zelle. 
Allerdings kann diese 
Verwendung-einer-2-Bit-MLC-Zelle-wie-eine-1-Bit-SLC-Zelle dann von den 
Fortschritten der Halbleitertechnik und von den geringeren 
Strukturbreiten profitieren, und bietet deshalb mehr Speicherplatz pro 
Fläche.

wendelsberg schrieb:
> Ich verwende fuer meine Heizungssteuerung/Datenerfassung eine Datei in
> /dev/shm also Ramdisk. Jede Nacht um 23:59 wird diese dann auf die
> SD-Karte transferiert. Das verringert die Zahl der Schreibvorgaenge auf
> 1/1440.
>
> mfG wendelsberg
Sehr interessante Idee!
Ja, wenn die Datenbank des TE darin ablegbar ist, könnte er die SD Karte 
im Betrieb ganz aus der Gleichung nehmen oder sie gar gänzlich nur als 
readable verwenden.

c-hater schrieb im Beitrag #5160972:
> BTW: postest du nebenbei auch mit anderen Accounts?
Nein.

c-hater schrieb im Beitrag #5160972:
> BTW: postest du nebenbei auch mit anderen Accounts? Weil: geantwortet
> habe ich Alex G. (dragongamer). Du gerierst dich allerdings, als wäre
> die Antwort an dich gerichtet gewesen. Kann es sein, dass du einen Teil
> deines Einkommens mit dem Verticken "besonderers ausgesuchter" SD-Karten
> erzielst?

Darf man in einem Forum nicht an allen Diskusionen teilnehmen solang es 
halbwegs Sinn macht (was heir der Fall ist)?

Phil schrieb:
> Mein Zwischenfazit ist: Wenn es zuverlässig sein soll lieber eine SSD
> per USB dran für den Betrieb.

Ja, kann man auch machen, sofern das nicht für das Projekt 
unverhältnismäßig oversized wird (die SSD ist ja größer als dr ganze 
raspi :D)

Schau dir aber auch mal Wendelsberg's Ansatz an. Das wäre eine richtig 
hübsche Lösung. Klappt natürlich nur wenn die Datenbank ohne Probleme in 
den RAM passt.

Von den ganzen diversen-Pi Computertypen und Usern habe ich immer wieder 
gutes gehoert von "Samsung EVO(+)" MicroSD-Karten - und gleich danach 
Sandisk Ultra/Extreme.

Die SanDisk Ultra und Extreme nutze ich und habe noch keine Ausfaelle.

Auch 2 Lexar-Karten laufen hier gut....

Und auch eine "alte" (4 Jahre) Samsung Class 10, die vorher die 4 Jahre 
dienst im Smartphone tat und nun da im Smartphone eine neuere ist - 
diese ihren Dienst noch im Pi tun darf.

Wenn ich dazu komme, sind die naechsten aber mal Sasmung EVO(+) 32GB

Schaut mal nach High Endurance Karten gibts von Sandisk, Lexar, 
Toshiba,... Kosten ein klein wenig mehr.

In der config.txt gibt einen Parameter für den Takt zur SD Karte dort 
kann man 25,50,75 und 100 einstellen. Standard ist 50 meine Sandisk 
Karten funktionieren alle mit 100 nur die Thosiba macht nur 75 mit.

Vielleicht bringt es ja etwas den Takt auf 25 runter zuschrauben.

Ansonsten auch mal folgendes um weniger Schreibzugriffe zu haben.
https://wiki.archlinux.de/title/Noatime

Alex G. schrieb:
> Schau dir aber auch mal Wendelsberg's Ansatz an. Das wäre eine richtig
> hübsche Lösung. Klappt natürlich nur wenn die Datenbank ohne Probleme in
> den RAM passt.

Und vor allem auch nur dann, wenn ein Stromausfall die Tagesdaten 
vernichten darf. Für eine Sportveranstaltung wäre das ziemlich doof.

Phil schrieb:
> Einziger Haken hierbei ist, das man ein wenig mehr Basteln muss als ein
> fertiges Linux Image auf die SD Karte zu schreiben.

Das kannst du im Zweifelsfall auch einmalig machen, daraus ein Image 
generieren und gut ist. Kann man auch für einen USB-Stick machen, um 
damit normale Notebooks zu befüttern, die sind im Zweifelsfall eher 
schnell verfügbar als ein RPi.

Phil schrieb:
> Die RAM Geschichte schont sicher die SD Karte und wäre in einer
> geschützen Umgebung sicher super, aber ich sehe die Gefahr, dass jemand
> über das Kabel stolpert auch als nicht so klein an. Und wenn die Daten
> dann nur im RAM sind ist alles vor dem letzten Sichern weg.

Du sagtest ja in deinem Startpost

Phil schrieb:
> (Daten gingen keine verloren,
> diese Werten zur Sicherheit live gedruckt.)

Daher bin ich mal davon ausgegangen, es sei keine Speicherung nötig.


Was SSD angeht - denke du musst nicht zwingend das OS darauf packen und 
ähnliche Umständliche Dinge. Es würde reichen, die Datenbank darauf zu 
packen.

Du kannst dein Linux auch komplett aus einer Ramdisk betreiben (d.h. die 
SD-Karte enthält nur Bootloader, Kernel und Initrd). Dann hast du auch 
garantiert keine Schreibzugriffe, die du nicht selbst veranlasst hast.

Für Backups bzw. allgemeines Verwaltungsgedöns ist SQLite vermutlich 
besser geeignet als MySQL (weil die Datenbank in genau einer Datei 
liegt), aber ob man das von PHP aus ansprechen kann, weiß ich gerade 
nicht.

Phil schrieb:
> Vielleicht mache ich zunächst tatsächlich einfach alles von einer SD
> Karte und mache alle paar Minuten einen Dump der Datenbank auf einen USB
> Stick.

Kannst du machen, musst nur aufpassen, dass dein Backup auch konsistent 
ist. Bei SQLite reicht es, die Datei zu kopieren, bei richtigen 
Datenbanken wie MySQL ist das nicht so einfach (die sind auf Dateiebene 
nicht konsistent).

Phil schrieb:
> Ich kenne SQLite leider fast nur vom Namen.
> Kann es denn das was MySQL kann?

SQLite ist eine vollwertige SQL-Datenbank, Trigger, Joins usw. werden 
unterstützt. Es ist aber kein MySQL, d.h. Sonderlocken gibt es keine 
(manche Anführungszeichen sind anders, weil MySQL da vom Standard 
abweicht).

c-hater schrieb:
> Und nein: USB-Stick für's root-Filesystem ist praktisch genauso Scheisse
> wie SD-Card.

Stimmt. Allerdings ist eine "USB Disk" nicht zwangsläufig ein "USB 
Stick". Es gibt USB-Adapter für M.2 SSDs. Auch als Huckepack-Platine für 
den Raspberry. Ich habe mit einer (anderen) Huckepack-Platine eine alte 
CF-Karte als Datenspeicher für den Raspberry recycelt.

Guido L. schrieb:
> "Samsung EVO(+)"

Bei den aktuellen Modellen wird das "+" zum "plus".

Phil schrieb:
> Ich würde einfach mysqldump verwenden und keine Dateien kopieren.

Das kannst du machen. Bei größeren Datenbanken wird das zum Flaschenhals 
(weil die Datenbank während des Dumps konsistent gehalten werden muss), 
aber in deinem Fall reicht das hin.

Stefan U. schrieb:
>> Du kannst dein Linux auch komplett aus einer Ramdisk betreiben
> Dafür bräuchter der kleine Computer allerdings mehr RAM.

Du kannst auf nem RPi keine 32 MB RAM für ein paar Binaries abzwacken? 
Zugegeben, ein komplettes Ubuntu kriegt man da nicht rein, aber das 
braucht der TO auch garnicht.

Meine Erfahrungen sind, das Karten gerne kaputt gehen, wenn Ihnen 
schlagartig die Spannung entzogen wird.
Gerade beim RPI, wenn er einfach ausgesteckt wird, während er gerade von 
der Karte schreiben / lesen probiert.
Da sind die USB Sticks besser geeignet.
Ich vermute mal, das die USB Sticks intern noch über Kondensatoren 
verfügen, welche den BrownOut buffern.

Stefan U. schrieb:
> Der Knackpunkt bei solchen Produktempfehlungen ist: Erst nach vielen
> Monaten guter Erfahrung kann man eine Empfehlung aussprechen.
Nicht unbedingt, denn ein Hersteller, der eine Firmware hat, wird die im 
Großen und Ganzen weiterverwenden. Und wie im 
Beitrag "Re: zuverlässige SD-Karte für Raspberry Pi" beschreiben, macht 
die Software gleich mal den Faktor 100 aus.

Letztlich ist es so, dass alle von mir bisher getesteten Samsung- und 
Toshiba-Karten im Dauerschreibtest gut waren. Und alle z.B. vom 
Hersteller Intenso waren schlecht, oder eben gerade gut genug für die 
Kamera oder das Handy, wo man eine Speicherzelle nur ein paar mal 
beschreibt.

Insofern empfehle ich jetzt jedem, der fragt einfach Samsung-Karten (und 
verwende die auch selber).

Fred R. schrieb:
> Meine Erfahrungen sind, das Karten gerne kaputt gehen, wenn Ihnen
> schlagartig die Spannung entzogen wird.
Wie definierst du "schlagartig"?

> während er gerade von der Karte schreiben ... probiert.
Das geht sowieso schief, denn das ist ja wie ins fahrende Auto 
einzusteigen. Da kannst du froh sein, wenn die Karte beim nächsten 
Booten noch ihre Firmware findet. Die ist nämlich auch auf dem Flash 
gespeichert...

Fred R. schrieb:
> Da sind die USB Sticks besser geeignet.
> Ich vermute mal, das die USB Sticks intern noch über Kondensatoren
> verfügen, welche den BrownOut buffern.

Wenn du einen USB-Stick oder eine SD-Karte im Betrieb rausziehst, werden 
die Datenleitungen vor den Versorgungsleitungen getrennt, was dem 
Controller etwas Zeit gibt. Das ist eine Folge der Hotplug-Fähigkeit.

Das gilt aber nicht, wenn du die Versorgung kappst, weder für SD-Karten 
noch für USB-Sticks. Und dann können beide gleichermaßen kaputt gehen. 
Technisch sind sich beide ohnehin sehr ähnlich.

S. R. schrieb:
> Wenn du einen USB-Stick oder eine SD-Karte im Betrieb rausziehst, werden
> die Datenleitungen vor den Versorgungsleitungen getrennt, was dem
> Controller etwas Zeit gibt.
Das bringt alles nichts, wenn eine 1MB große Datei geschrieben werden 
soll und erst 500kB übertragen sind...

c-hater schrieb:
> Es geschehen noch Zeichen und Wunder... Dass wir beide mal einer Meinung
> wären, hätte ich echt nicht gedacht.

Solange du es schaffst, den dritten Buchstaben des Alphabets nur in 
inniger Verbindung mit anderen Buchstaben zu nutzen... ;-)

S. R. schrieb:
> Wenn du einen USB-Stick oder eine SD-Karte im Betrieb rausziehst, werden
> die Datenleitungen vor den Versorgungsleitungen getrennt, was dem
> Controller etwas Zeit gibt. Das ist eine Folge der Hotplug-Fähigkeit.
>
> Das gilt aber nicht, wenn du die Versorgung kappst, weder für SD-Karten
> noch für USB-Sticks. Und dann können beide gleichermaßen kaputt gehen.
> Technisch sind sich beide ohnehin sehr ähnlich.

Korrekt. Abhilfe kann da eine USB schaffen, von denen es für den RasPi 
eine ganze Reihe gibt. Die erkennt einen Stromausfall, puffert ihn mit 
ihrem Akku ab und veranlasst den Pi, geordnet herunterzufahren.

Ansonsten kann man jede moderne Datenbank wie MySQL, PostgreSQL entweder 
in einem HA-Cluster betreiben, oder sogar als geshardeten und 
replizierten DC-Cluster (etwa PostgreSQL-XL). Die meisten 
NoSQL-Datenbanken sind sogar von vorneherein dafür ausgelegt.

USB -> USV?

Also mit einem USB Stick fürs rootFS kann man den RasPI schon hart 
abschalten und es passiert nix.
Das wird bei dem Teil jetzt schon seid Jahren so praktiziert:
http://www.fritzler-avr.de/HP/dasuhr.php

Das Teil wird mit dem 230V Schalter ein und abgeschalten.
Die SD Karte hats dabei regelmäßig gefressen.

Allerdings dürfte das beim DB wegschreiben trotzdem noch zu Fehlern 
führen da es da mehr Schreibzugriffe gibt.

Thomas S. schrieb:
> USB -> USV?

Äh, ja.

Die neueren Raspberries können auch ganz ohne SD aus dem Netz booten:

https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/net_tutorial.md


Braucht man natürlich einen Server, dafür könnte man den o.g. Laptop 
nehmen.

Den RPI3 kann man von USB Platte oder Stick starten!
Verwende meine Sticks jetzt schon ewig und hatte bis jetzt noch nie 
Probleme.
Man soll halt nur nicht die aus einem Schütgutregal eines Diskounters 
verwenden.



*Ja. Zwanzig Leute wissen es jetzt sicher besser, dass man von USB NICHT 
starten kann sondern nur von der SD Karte.

Aber was sagt die offizielle RPI Seite dazu?
https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md

20TB schrieb:
> Wenn so 'ne SD Karte übern Jordan geht, hängt dann das gesammte Linux
> oder wird ein "medium error" wie bei den HDDs gemeldet?

Im Betrieb ist mir bisher keine gestorben, aber kaputte SD-Karten werfen 
meistens eindeutige Meldungen oder es passiert schlicht überhaupt 
nichts. Eine Karte hat mir aber das System blockiert, bis ich sie wieder 
rausgezogen hatte (im Laptop-eigenen Kartenleser).

Stefan U. schrieb:
> Wir sind nicht blöde.
Das wurde auch nirgends behauptet...

> Es geht natürlich um den verlust der bereits
> geschriebenen Daten, insbesondere der Dateien, die abgeschlossen wurden.
Das ist übrigens einer der Effekte von "schlechten" Karten: Dateien, die 
nur 1x geschrieben und ab dann nur noch gelesen werden, sind auf einmal 
korrupt. Das fiel hier bei Sprachdateien auf, die Meldungen in 
verschiedenen Sprachen gespeichert hatten: nach und nach tauchten 
seltsame Texte mit falschen Buchstaben auf. Ein Vergleich der Dateien 
mit den Ausgangswerten zeigte dann, dass einzelne Bits in Richtung '1' 
umgekippt waren. Das ist das erste Zeichen für das baldige Ende der 
Karte.
Und wenn letztlich in der (ebenfalls statischen) Programmdatei einzelne 
Bits umkippen, dann passiert alles Mögliche... :-o

Andi_73 schrieb:
> Lothar M. schrieb:
>> Dateien, die
>> nur 1x geschrieben und ab dann nur noch gelesen werden, sind auf einmal
>> korrupt.
>
> Diesen Effekt habe ich auch schon bei USB Sticks beobachtet.
> Liesst man den USB Stick mit HD Tune aus
> sollte sich eine gerade Linie ergeben.
> Jedoch ist die Geschwindigkeit verschieden und niedriger.
>
> Kopiert man alle Daten neu auf den Stick ist wieder alles gleich schnell
> zu lesen.
Sicher dass du die selben Daten wieder draufkopiert hast, und nicht nur 
HDtunes Schreibtest?

Bei normalen Daten die sich in ihrer Größe erheblich unterscheiden, ist 
es normal dass die Kopiergeschwindigkeit schwankt. Das ist bei HDDs 
genau so.

Interessante Daten!
War sicher einiges an Mühe!

Ein paar Fragen aber:
1. Sind schwankungen bei den Tests da, oder kamen bei Wiederholungen, 
stets sehr ähnliche Werte raus?
2. Wofür steht EurEx?
3. Sind das alles Megabytes, oder Megabits?

Ein Ausfall-Test wäre durchaus interessant. Allerdings wirst du das wohl 
automatisieren müssen, denn soo häufig kommt das ja nicht vor.
Bin mal gespannt :)

Sehr interessant dass die Bootzeit bei f2fs schon deutlich kürzer ist.
Hat das Filesystem irgendwelche Nachteile?


Btw. falls du einen Lebensdauer-Test machst, mach bitte einen wo z.B. 
nur eine 10Kb Datei wieder und wieder, an den Selben Pfad geschrieben 
wird.
Das ist ein viel realistischeres Anwendungsscenario und man kann sehen 
ob die Karten (oder wahrscheinlicher die STicks) ein funktionierendes 
Write-Balancing wie SSDs haben.

ansonsten mal nach "high endurance" Karten schauen.

Nach 4 mal Vollschreiben, Probleme, ist dann doch etwas übertrieben.
Bin mir ziemlich sicher dass ich in meinem alten Smartphone um das 
Mehrfache drüber hinaus gekommen bin und in Kameras (vorallem 
Actioncams) werden sie auch sehr häufig eingesetzt.

Probleme haben sie halt im Falle des Raspberry's da dessen Fileformat, 
die Bemühungen der Hersteller zunichte macht.
Dieses F2FS Format - welches grad für Flash Friendly File System steht, 
klingt darum besonders interessant.

c-hater schrieb:
Warum
> sollte man mir auch glauben, schließlich ist die Werbung ja sehr viel
> vertrauenswürdiger. Das ist ja per default die reine unbefleckte
> Wahrheit, isn't it?

Werbung.. dein Ernst?
Und die riesige Community die Spezial-Lösungen wie SSD oder USB Stick 
nur in Ausnahmefällen einsetzt, kehrst du mal einfach so unter den 
Tisch?

>
> Übrigens, was SSDs betrifft:die sind um ein Vielfaches besser als dieser
> Billichscheiss von USB-Sticks oder SD-Cards. Genau deswegen kosten sie
> aber auch erheblich mehr und deswegen brauchen sie auch deutlich mehr
> Energie.


c-hater schrieb:
> Würde man sich dann nicht fragen, wie es sein kann,
> dass bei gleicher Kapazität so ein USB-Stick oder so eine SD-Card so
> viel billiger sein kann und mit soviel weniger Energie auskommen kann?
> Wie zum Teufel geht das?
Erstmal Geschwindigkeit. Eine MicroSD nutzt niemand in einem PC als 
Systemplatte.
Hättest du meine Beiträge weiter oben gelesen (Lesen ist auch ein 
Vorteil ;) ), wüsstest du sehr wohl dass ich weiss was an einer SSD 
anders ist.

Überhaupt SSD mit MicroSD zu vergleichen macht doch selten bis nie Sinn. 
So ähnlich wie Äpfel mit Birnen. Sind beides Früchte und man kann sie 
essen, aber mehr haben sie auch nicht gemeinsam.


Torben schrieb:
> Und kann man sagen, was in so einem Samsung Handy als Flash-Speicher
> steckt? Ist das eher mit einer SSD vergleichbar oder das Billigste vom
> Billigen?
>
> Oder anders gefragt: Lässt sich tatsächlich ein Teil der zunehmenden
> "Langsamkeit" der Smartphones über das Altern des Flashs erklären?

Durchaus interessante Frage.
Orientiere dich aber nicht an c-hater's Antwort. Er hat weiter oben 
schon völligen Quatsch verbreitet und hat kaum eigene Daten.

Es gibt Apps mit denen man die Schreib-Geschwindigkeit einfach testen 
kann. Wenn du ein neues Phone bekommst, lass sowas mal laufen.
Speicher-Geschwindigkeitstests sind leider in Smartphone-Tests eher 
nicht zu finden :(

Btw. langlebiegr Flash dürfte wohl nicht so teuer sein. Das Raspberry 
Compute Module 3 in der nicht-lite Version hat 4Gb Flash auf dem PCB 
drauf. Dabei richtet sich das Teil an professionelle Einsätze in 
Messgeräten und Ähnliches. Die Lebensdauer dürfte somit ordentlich sein 
und kosten tut das Teil nur wenig mehr als der normale Raspi 3.

Dieter schrieb:

> Ich kaufe nur noch Speicherkarten von Samsung, hatte sonst mit allen
> möglichen Herstellern öfters Ausfälle (Transcend, SanDisk, etc.), bei
> Samsung hatte ich keinerlei Probleme, die laufen reibungslos in allen
> Anwendungen, sei es DSLR, Kampera, 4k Action Kamera, Root FS, Raspberry,
> noch keinen einzigen Ausfall gehabt.

Transcend hat keine eigene Fertigung, die kaufen zusammen, was am Markt 
zu haben ist oder lassen vielleicht auch mal (hoffentlich) 
Auftragsfertigen. Von daher ist meine Wahl der Transcend als billige 
Alternative zur Sandisk etwas riskant.

Jedenfalls ist es empfehlenswert, solche "NoName" Karten vor dem Einsatz 
mittels iozone zu testen und mit einem "Muster" zu vergleichen. Es ist 
naemlich bei solchen Lieferanten durchaus NICHT sicher, dass in einer 
Karte gleicher Type auch wirklich immer das gleiche drinsteckt (naja, 
ist es eigentlich bei den anderen Herstellern auch nicht 100% ...) oder 
gar ein Fake ist (jaja, sowas gibt es, wenn man 20ct sparen will und 
beim Chinamann bestellt ;-)  )

Von Sandisk hatte ich mal eine von Anfang an kaputte (Schreibfehler) 
Ultra aus dem Bloedmarkt, vielleicht war das aber auch ein Fake. Als 
100% serioese Quelle wuerde ich diesen Markt ja nicht gerade einstufen, 
aber welcher Haendler ist das heute noch.

Von daher ist Deine Entscheidung fuer Samsung keine so schlechte Idee. 
Wobei auch Samsung hie und da daneben haut, siehe meine Testergebnisse 
fuer die "Samsung Evo+ 32GB" und den "besseren" Nachfolger "Samsung Evo 
Plus 32GB", der um Faktoren SCHLECHTER ist bei iozone random write :-(

Ich haette ansonsten die "Samsung Evo+ 32GB" anstatt der Sandisk Extreme 
gewaehlt, aber die gibts ja nur mehr in Restbestaenden, das nuetzt mir 
nix (brauche Stueckzahlen).

P.S.: Ich bins, Bernhard. Habe mir endlich einen Account hier besorgt 
(lesend greife ich auf mikrocontroller.net schon etliche Jahre zu)

Wenn ich auf die eine Karte X Terabyte schreibe, bevor sie kaputt geht 
und auf die andere nur X/10 bei gleicher Kartengroesse, dann ist das 
schon ein Ergebnis bezueglich der Haltbarkeit.

Thomas schrieb:
> Das nenne ich eine messerscharfe Analyse. Du hast bestimmt Abitur.
Das geht auch ohne Abitur. Und es ist ohne firmeninternes Wissen zu 
haben die einzige realistische Methode. Siehe dazu den 
Beitrag "Re: zuverlässige SD-Karte für Raspberry Pi"

Hast du eine bessere Teststrategie oder willst du nur auch mal irgendwas 
zum Thema gesagt haben?

Thomas schrieb:

> Das nenne ich eine messerscharfe Analyse.

Wollte es nur einfach darstellen, damit Du es auch verstehst ;-)

> Du hast bestimmt Abitur.

Noch schlimmer: Zusaetzlich noch 2 Ingenieurdiplome und > 25 Jahre 
Berufserfahrung in beiden Branchen.

Spass beiseite: Wenn Du eine bessere Idee hast, wie man die Haltbarkeit 
verschiedener SD-Karten wenigstens grob klassifizieren kann, als mit 
einem der entsprechenden Anwendung analogen Schreibmuster die Dinger 
kaputtzumachen, dann immer her damit.

Die "plus" waere dann schon neu nur auf dem level Deiner viel 
beschriebenen "+". Mag mir den Rest gar nicht weiter vorstellen....

Dabei ist die "plus" der Nachfolger der "+" und laut Aufdruck noch 
schneller (und auch teurer). Naja, im Fotoapparat vielleicht.

Echt schade, die "+" haette mir sehr gut in den Kram gepasst. So bleibt 
mir auf diesem Leistungslevel nur noch die (nochmal deutlich teurere) 
"SanDisk Extreme 32GB" (ohne "Pro" !!!) uebrig.

Thema: uSD totschreiben
=======================

Bin nun seit einiger Zeit dabei, erst mal die billige xlyne SDHC 8GB 
(7408001) mit ext4 (noatime, ordered) totzuschreiben. Das mache ich auf 
einer 5GB Datenpartition (die restlichen 2.4GB sind ebenfalls 
partitioniert und mit ext4 formatiert, sodass sie von der uSD nicht zum 
wearleveling herangezogen werden koennen).

* Rpi startet vom USB-Stick, da ist die Testsoftware drauf
* Testprogramm erstellt auf uSD eine 1MB Datei macht folgendes:
  * 1MB 0x55 schreiben (Posix write)
  * fsync (Posix)
  * 1MB lesen und pruefen, ob 0x55 drin steht (Posix read)
  * 1MB 0xAA schreiben (Posix write)
  * fsync (Posix)
  * 1MB lesen und pruefen, ob 0xAA drin steht (Posix read)

Diverse Logs ueber den Verlauf werden auf den USB-Stick geloggt.

Inzwischen wurden ca. 1GB Daten (also 1024 x 1MB) geschrieben, also 
jeder Sektor der Datei eben 1024 mal. Die uSD zeigt keinerlei Probleme, 
nicht mal die Datenrate ist zurueckgegangen (konstant bei ca. 3.7MB/s 
schreiben+lesen).

Das ist schon eine (angenehme) Ueberraschung.

Hat jemand eine Idee, ob nicht doch irgend ein Fehler im Testalgorithmus 
stecken koennte?
Dem fsync sollte man wohl trauen koennen, sonst ist sowieso alles 
verloren ;-) .

Bernhard R. schrieb:
> Dem fsync sollte man wohl trauen koennen, sonst ist sowieso alles
> verloren ;-) .

Dem fsync() kannst du soweit trauen, dass dein Linux die Daten an die SD 
abgegeben hat. Ob die Daten dann auch im Flash sind, ist nicht 
garantiert, aber relativ wahrscheinlich (sonst wäre die Datenrate 
höher). Außerdem kann es sein, dass dein Linux die Daten aus dem 
Plattencache liest und nicht vom Device.

Deine Testdatenmenge ist kleiner als ein Eraseblock, der Controller wird 
also deine gesamte Datei cachen (und möglicherweise auch die 
inode-Zugriffe). Die Chancen stehen dadurch äußerst gut, dass du deine 
Antwort aus diesem Cache beziehst, nicht aus den real im Flash 
gespeicherten Bits - wenn Linux überhaupt von der Karte liest.

Du beschreibst immer nur die gleichen Blöcke des Devices, also hast du 
den optimalen Fall für das Wear-Levelling. Deine Testdatei wird also 
schön gleichmäßig durch den gesamten Flash wandern.

Es gibt zwar ein wenig Write Amplification (weil überall ein Dateisystem 
drauf ist), aber ob die eigentlichen Datenbereiche deines Dateisystems 
vom Controller als "leer" angesehen werden (mke2fs nutzt standardmäßig 
TRIM) oder nicht, kann ich nicht einschätzen.

Aus meiner Sicht betreibst du ein beinahe-best-case-Schreibszenario und 
wirst Fehler erst nach einem Reboot feststellen. Deine Datenmenge ist zu 
klein.

Vielen Dank fuer den Input, hat mir einige Ansaetze zum Nachdenken 
gegeben.

Ich bin wie Du sehr sicher, dass fsync die Daten wirklich auf die uSD 
schreibt, dafuer gibt es etliche Hinweise und keinen, der dagegen 
spricht.

Was ich nicht bedacht habe ist, dass aufgrund der "kleinen" Dateigroesse 
von 1MB die gelesenen Daten vermutlich wirklich aus dem Cache kommen und 
das Ruecklesen damit eher wertlos ist. Das hat aber mit dem Schreiben 
selbst nichts zu tun und ich kann ja zwischendurch mal rebooten um zu 
sehen, ob die Datei noch in Ordnung ist (habe ich auch schon gemacht, es 
ist noch immer alles in Ordnung).

In der Sache mit TRIM hast Du aber (leider) recht. Die "discard" Option 
ist zwar beim mount default ausgeschaltet, ich hatte aber bisher nicht 
gewusst, dass mkfs.ext4 beim FORMATIEREN "discard" defaultmaessig 
eingeschaltet, also ein einmaliges TRIM macht. Vielen Dank nochmal fuer 
diese sehr wertvolle Information!

Das heisst also, dass alleine durch das formatieren dem uSD Controller 
mitgeteilt wird, welche Sektoren vom Filesystem erst mal nicht benutzt 
werden (und das sind fast die gesamten 8GB, da meine Testdatei ja nur 
1MB gross ist). Diese Sektoren kann der uSD Controller zum werar 
leveling heranziehen.

Ob die uSD Karte das TRIM akzeptiert und ob daraus folgend wirklich ein 
wear leveling gemacht wird, haengt von der uSD Karte ab. Angesichts der 
der grossen problemlos geschriebenen Datenmenge von 1TB gehe ich fuer 
meine Testkarte davon aus.

Allerdings ist der Test nicht ganz wertlos, immerhin wurden tatsaechlich 
1TB Daten geschrieben. Trotz vermutetem wear leveling wurde jeder Sektor 
also bisher mindestens 128 mal (1024/8) beschrieben, so schlecht ist das 
nicht fuer diese billige Karte.

Beachten sollte man jedenfalls, dass das wear leveling nur gut 
funktioniert, wenn genug unbenutzte Sektoren vorhanden sind. Der alte, 
aber gute Trick, eine mehrfach groessere Karte zu verwenden, als man 
letztlich Daten draufschreiben will, hat also durchaus seine 
Berechtigung. Das gilt AUCH fuer das f2fs.

Da man aber nie sicher sein kann, ob die uSD TRIM und damit das wear 
leveling wirklich unterstuetzt, rate ich trotzdem nach wie vor zum f2fs, 
das durch die log-Struktur ein wear leveling quasi auf FS-Ebene 
eingebaut hat (und es schreibt kleine random Daten um Faktoren 
schneller, das ist bei einer DB Anwendung wichtig).

Ich werde meinen Test nun so abaendern, dass ich die Partition(en) mit 
"nodiscard" neu formatiere. Somit kann die uSD maximal noch mit 
eventuell vorhandenen Reservesektoren wear leveling machen (was auch ok 
ist).

Alternativ koennte man eine zweite Testdatei anlegen, die das ganze FS 
fuellt. Auch in diesem Fall kann die uSD nur noch mit den 
Reservesektoren wear leveling betreiben.

Das Problem mit dem ruecklesen aus dem Cache muss ich noch loesen, damit 
ich zuverlaessig, rechtzeitig und automatisch den Tod der Karte 
feststellen kann.

Einwaende?

soul e. schrieb:
> Ein echter wear levelling-Algorithmus verwendet stets den kompletten
> Speicher. Sobald die Blöcke der ersten Partition eine gewisse Abnutzung
> erreicht haben, werden diese gegen Blöcke der zweiten Partition
> getauscht. Das Umkopieren erfolgt natürlich so, dass der Anwender keinen
> Unterschied merkt.

Das ist zu allgemein und daher nicht wirklich korrekt.

Wenn man die uSD partitioniert inklusive Filesystem drauf, kann der uSD 
Controller mit diesen Speicherbereichen KEIN wear leveling machen, weil 
der Controller i.a. keine Ahnung von Filesystemen hat (jedenfalls nicht 
von ext4). Das kann er nur, wenn Linux mitteilt, welche Sektoren 
unbenutzt sind.

Das tut Linux bei ext4 ueber die "discard" Option beim formatieren 
(default on, einmalig) und beim mounten (default off, wiederholt) bzw. 
ueber ein manuelles trim.

Wenn man diese Moeglichkeiten ausschaltet, kann die uSD kein wear 
leveling machen, jedenfalls nicht mit den von den Partitionen belegten 
Speicherbereichen, hoechstens mit eventuell vorhandenen Reservesektoren, 
auf die Linux sonst keinen Zugriff hat.

soul e. schrieb:

> Der Controller interessiert sich nicht für Filesysteme.

Das stimmt so nicht. Viele (die meisten?) uSD Controller sind fuer FAT 
optimiert. Deshalb ist es ja gerade so problematisch, eine Consumer-uSD 
mit einem anderen FS zu nutzen, z.B. ext4 und dann noch dazu in einem 
Rpi, der ein voellig anderers Zugriffsmuster hat als eine Kamera. FAT 
ist fuer eine Rpi-Nutzung aber leider auch eine schlechte Idee wegen der 
random Zugriffsmuster.

Soweit mir bekannt, erloeschen diverse Garantien von uSD Herstellern 
("Lebenslange Garantie") auch sofort, wenn man die uSD umformatiert oder 
z.B. in einem Raspi einsetzt.

> Wenn ein Block
> mehrfach beschrieben wurde und ein anderer nur einmal, dann tauscht er
> den Inhalt dieser beiden Blöcke gegeneinander aus. So wird dann der
> andere abgenutzt. Das ist vom Dateisystem vollständig unabhängig und für
> den Anwender unsichtbar.

Das kann er aber nur, wenn er freie/unbenutzte Sektoren zur Verfuegung 
hat. Nur woher nimmt er die freien Bloecke, wenn die uSD zu 100% von 
einem nicht-FAT Filesystem belegt ist? Dafuer gibt es nur 2 
Moeglichkeiten:

1) Die uSD beherrscht den TRIM Befehl und das OS/FS benachrichtigt den 
uSD-Controller mittels TRIM ueber dzt. freie/ungenutzte Sektoren.

2) Auf der uSD sind Reservesektoren vorhanden, die alleine der 
uSD-Controller verwaltet. Diese sind von aussen unsichtbar, deshalb 
weiss das OS/FS nichts davon und der uSD-Controller kann sie frei 
verwenden. Unter anderem an diesem Punkt (Anzahl der Reserve-Sektoren) 
trennt sich die Spreu vom Weizen bei den uSD Karten.

Nur wenn 1) und/oder 2) bei einer komplett mit einem FS belegten uSD 
gegeben ist, kann der uSD Controller ueberhaupt ein wear leveling 
machen.

soul e. schrieb:
> Falsch. Es werden häufig geschriebene mit Userdaten belegte Blöcke gegen
> seltener beschriebene mit Userdaten belegte Blöcke getauscht. Zum
> Umkopieren wird natürlich temporär ein einzelner freier Block als
> Zwischenspeicher benötigt.

Der Controller kopiert überhaupt keine Blöcke um. Das wäre viel zu 
uneffektiv. Der Wearleveling-Algorithmus benutzt für einen logischen 
Block X einfach unterschiedliche physikalisch Blöcke. Aber es wird 
niemals der Inhalt umkopiert. Beim einem Schreibzugriff (und nur dann) 
von Block X sucht er sich einen neuen physikalischen Block, wenn das 
wear-leveling es vorgibt.

soul e. schrieb:
> Das ist das, was ich als "umkopieren" bezeichnet habe

Der Controller kopiert aber nichts um.
Das was du hier (siehe unten) beschrieben hast, macht nicht der 
Controller für den Nand-Speicher und auch nicht das wear-leveling. Das 
ist schlicht falsch, so wie du es beschrieben hast.

soul e. schrieb:
> Zum Tauschen sind drei Schreibvorgänge notwendig: A-->temp, B-->A,
> temp-->B.

900ss D. schrieb:
> Der Controller kopiert aber nichts um.
> Das was du hier (siehe unten) beschrieben hast, macht nicht der
> Controller für den Nand-Speicher und auch nicht das wear-leveling. Das
> ist schlicht falsch, so wie du es beschrieben hast.

Das wäre allerdings imho die einzige Möglichkeit (und technisch einfach 
zu realisieren) um den Ausfall der Zellen zu verhindern. Hast du eine 
Quelle dafür, dass kein Controller so vorgeht? ;-)

Mikro 7. schrieb:
> Hast du eine Quelle dafür, dass kein Controller so vorgeht? ;-)

:)

Gute wear-leveling Algorithmen werden von den Herstellern gut gegen 
Einsicht geschützt. Das war jedenfalls meine Erfahrung als ich vor 3-4 
Jahren mich damit beschäftigt habe.

Servus miteinander,

sehr interessantes Thema wie ich finde und danke an Bernhard erstmal für 
die Arbeit.

Ich hatte den gleichen Gedanken wie soul eye

soul e. schrieb:
> Es werden häufig geschriebene mit Userdaten belegte Blöcke gegen
> seltener beschriebene mit Userdaten belegte Blöcke getauscht.

und auch wenn der Einwand von 900ss

900ss D. schrieb:
> Der Controller kopiert überhaupt keine Blöcke um. Das wäre viel zu
> uneffektiv. Der Wearleveling-Algorithmus benutzt für einen logischen
> Block X einfach unterschiedliche physikalisch Blöcke. Aber es wird
> niemals der Inhalt umkopiert.

mit Sicherheit berechtigt ist, ändert es dennoch nichts an der Tatsache, 
dass der uSD-Controller dem Benutzer lediglich logische Adressen gibt 
und die physikalischen Adressen sich ändern können wie er (der 
Controller) es für richtig hält. D.h. meiner Meinung nach trifft 
folgendes nicht zu

Bernhard R. schrieb:
> die restlichen 2.4GB sind ebenfalls
> partitioniert und mit ext4 formatiert, sodass sie von der uSD nicht zum
> wearleveling herangezogen werden koennen

Der Zusammenhang zwischen uSD, deren Partitionierung und FAT32 als 
Dateisystem ergibt sich - soweit ich das verstehe - daraus, dass die 
Dateisystemtabelle (FAT) an einer logischen Adresse liegt, welche 
gesondert behandelt wird. Das ist in sofern sinnvoll, da Änderungen am 
Dateisystem häufig vorkommen. Zu diesem Zweck mappen die uSD-Controller 
diese logische Adresse wenn möglich in einen Speicher, welcher aus 
SLC-Speicherzellen besteht und somit zum einen höhere Schreib- und 
Leseraten erlaubt und zum anderen häufiger beschrieben werden kann. Das 
grundsätzliche Problem, was den Einsatz einer uSD in RPi und Co angeht 
sehe ich darin, dass diese Geräte typischerweise mindestens zwei (und 
normalerweise noch mehr) Partitionen besitzen, wofür die SD-Karten an 
sich nie ausgelegt waren.

Hier sind noch zwei Quellen zu dem Thema:

http://3gfp.com/wp/2014/07/formatting-sd-cards-for-speed-and-lifetime/
http://wiki.laptop.org/go/How_to_Damage_a_FLASH_Storage_Device

Es gibt  zwei war leveling Methoden. Static Wear leveling und dynamic 
Wear leveling oder  auch mixed.
Beim static Wear leveling werden tatsächlich Blöcke umkopiert. Findet 
aber in Sd-Karten eher nicht statt. Bei z.B. SSDs schon. Das soll 
verhindern, dass die Blöcke mit "alten" Daten auch beim wear leveling 
berücksichtigt werden. Die würden ja sonst dem Algorithmus nicht zur 
Verfügung stehen und so die Gesamtlebensdauer des Speichers verringern 
will weniger Blöcke genutzt werden können.

Also ich korrigiere meine Aussage insoweit, dass in SD-Karten nicht 
umkopiert wird. Um diesen Speicher geht es hier ja.

900ss D. schrieb:
> Also ich korrigiere meine Aussage insoweit, dass in SD-Karten nicht
> umkopiert wird. Um diesen Speicher geht es hier ja.

Nehmen wir den hypothetischen Fall an, dass (1) eine Page einem Block 
entspricht und dass (2) lediglich ein Block reserviert ist (zusätzlich 
zum nach außen sichtbaren logischen Adressraum).

Wenn nun der Client immer den gleich LBA schreibt, müsste der 
reservierte Block beschrieben werden. Der (alte) Block, der dem LBA 
vorher zugeordnet war, wird zum neuen (freien) reservierten Block.

Beim nächsten Schreibzugriff auf den selben LBA passiert das gleiche. 
Usw. usf. Es würden also ständig nur zwei Blöcke beschrieben, was zum 
baldigen Ableben führen würde.

In der Praxis ist das etwas komplexer, aber imo mit einem ähnlichen 
Effekt.

Woher kommt deine Annahme, dass keine SD-Card Software das (durch 
umkopieren) abfängt. Ich kann mir durchaus vorstellen, dass es Software 
gibt, die das nicht macht. Aber die Behauptung, dass es das auf SD-Card 
grundsätzlich nicht gibt, irritiert mich etwas.

Bernhard R. schrieb:
> Das mache ich auf einer 5GB Datenpartition (die restlichen 2.4GB sind
> ebenfalls partitioniert und mit ext4 formatiert, sodass sie von der uSD
> nicht zum wearleveling herangezogen werden koennen).
Dir sollte eines klar sein: du kannst auf diese rein logische und 
völlig abstrakte Weise nicht steuern, welcher Teil des physikalischen 
Flashs mit welchen Daten beschrieben wird.

Bernhard R. schrieb:
> Beachten sollte man jedenfalls, dass das wear leveling nur gut
> funktioniert, wenn genug unbenutzte Sektoren vorhanden sind.
Wobei "ungenutzt" nicht "ohne Inhalt und Information" bedeutet. Es 
reicht z.B. schon aus, wenn Teile des Flashs mit statischen Daten belegt 
sind. Denn die werden dann einfach in einen schon häufig benutzen Block 
verschoben und voilà: ein leerer und fast unbenutzter Block ist 
entstanden...

Lothar M. schrieb:
> Wobei "ungenutzt" nicht "ohne Inhalt und Information" bedeutet. Es
> reicht z.B. schon aus, wenn Teile des Flashs mit statischen Daten belegt
> sind. Denn die werden dann einfach in einen schon häufig benutzen Block
> verschoben und voilà: ein leerer und fast unbenutzter Block ist
> entstanden...

Das wäre ja genau das (wenn ich es richtig interpretiere) was lt. @ 
900ss bei SD-Cards gerade nicht passiert. Hast du denn eine Quelle für 
deine gegenteilige Behauptung?

Mikro 7. schrieb:
> Es würden also ständig nur zwei Blöcke beschrieben, was zum baldigen
> Ableben führen würde.

Du hast es nicht richtig verstanden. Das wear-leveling nutzt alle 
Blöcke, die frei sind. Reserveblöcke werden in der Regel vom BBM (bad 
block management) genutzt, wenn ein Block als defekt erkannt wird (erase 
schlägt fehl, program schlägt fehl, Daten werden mehrfach mit 
korrigierbaren Fehlern gelesen oder nicht korrigierbare Daten werden 
gelesen).
In der Regel sind Wear-leveling und BBM zusammen im Flash Management 
Layer (FML) untergebracht.

Wenn es natürlich nur noch einen freien Block geben sollte, hast du 
Recht.

Es gibt genug Papers im Netz dazu, allerdings keine expliziten 
Algorithmen. Die sind gut geschützt.

Es ist wirklich ein spannendes Thema finde ich.

Lothar M. schrieb:
> Dir sollte eines klar sein: du kannst auf diese rein logische und
> völlig abstrakte Weise nicht steuern, welcher Teil des physikalischen
> Flashs mit welchen Daten beschrieben wird.

Dass man (das OS, das FS) nur logische Sektoren ansprechen kann, ist 
klar. Anders waere ein waer leveling sowieso kaum machbar.

Du uebersiehst aber einen entscheidenden Punkt: Es geht letztlich um die 
GROESSE des Datenbereiches, nicht um seine Lage. Wenn die Karte 8GB hat, 
die 8GB mit einem Filesystem belegt sind und das OS dem Controller nicht 
mitteilt, welche Sektoren keine Daten enthalten (siehe TRIM), wird es 
fuer den uSD Controller sehr schwer mit dem wear leveling.

Genau das war auch der Ausgangspunkt, dass ich versuche, eine Karte 
absichtlich kaputtzuschreiben, also moeglichst unguestig zu belasten. 
Einfach um zu sehen, wie lange sie beim "worst case" durchhaelt.

Das ist fuer mich ein wichtiger Aspekt, denn gerade bei Verwendung einer 
uSD in einem Raspi gehe ich davon aus, dass der worst case vielleicht 
doch mal unbemerkt eintritt.

Wenn eine Karte das wear leveling dann besser macht als von mir 
unterstellt und laenger haelt: Gerne!

> Wobei "ungenutzt" nicht "ohne Inhalt und Information" bedeutet. Es
> reicht z.B. schon aus, wenn Teile des Flashs mit statischen Daten belegt
> sind. Denn die werden dann einfach in einen schon häufig benutzen Block
> verschoben und voilà: ein leerer und fast unbenutzter Block ist
> entstanden...

Ich kann mir nicht vorstellen, dass so ein uSD Controller DARUEBER auch 
noch Buch fuehrt. Vielleicht bei einer SSD, aber nicht bei einer 
(billigen) uSD, die noch dazu "auf Fotoapparate optimiert" ist.

Nicht falsch verstehen, WENN die uSD Controller so intelligent waeren, 
umso besser. Ich denke aber, dass deren wear leveling nur SEHR 
rudimentaer ist. Bis vor wenigen Jahren gab es uSD Karten, die sowas 
ueberhaupt nicht hatten.

Was ich will ist, die worst case "Haltbarkeit"  fuer ein paar wenige 
spezielle Typen (die ich eben zukuenftig einzusetzen gedenke) 
abzuschaetzen. Zum einen zum Vergleich dieser Kartentypen und zum 
anderen, um ruhiger schlafen zu koennen :-)

Karl schrieb:
> Irgendwo muss sich der Controller merken, wie oft er welche Blöcke
> beschrieben hat, und das ausfallsicher. Welchen Speicher nutzt er denn
> dafür, der muss ja mindestens so robust sein wie der Flash? Eeprom?

Das geht im Prinzip schon, einfach einen kleinen Metadatenbereich (ein 
paar Bytes) im Block reservieren und dort einen Schreibzaehler 
unterbringen, der zusammen mit den Daten bei jedem Loesch+Schreib 
Vorgang aktualisiert wird.

Z.B. bei kleineren SPI-Nor Flash (um die es hier nicht geht, aber es 
geht ums Prinzip) ist es oft so, dass pro Block ein paar Bytes mehr zur 
Verfuegung stehen (z.B. AT45DB Dinger, 528 Byte statt 512 pro Page), 
damit man schoene 2er Potenzen fuer den Datenbereich hat und man 
wirklich die angegebene Groesse rein fuer Nettodaten zur Verfuegung hat.

Das habe ich selbst schon praktisch genau so in einer Anwendung gemacht.

Woran ich zweifle ist, dass die uSD Controller intelligente und 
ausgefuchste wear leveling Algorithmen haben. Woran ich noch mehr 
zweifle ist, dass die fuer Fotoapparate gedachten Consumer Karten gut 
geeignet sind fuer Rpi Anwendungen.

Deshalb versuche ich herauszufinden, ob ein paar der Kartentypen, die 
ich ins Auge gefasst habe (weil das Preis/Leistungsverhaeltnis ungefaehr 
passt), ZUVERLAESSIG GENUG sind fuer die Verwendung im Rpi.

Das ist auch ueberhaupt Ursprung des ganzen Thread, der da heisst: 
zuverlässige SD-Karte für Raspberry Pi

Es geht also nicht darum, was moeglich waere oder was die eine oder 
andere Karte oder SSD macht, sondern wie zuverlaessig einige uSD Karten 
sind in einem Einsatzfeld, fuer das sie nie vorgesehen waren.

Eine Bitte!

Da mir der Thread etwas abgeschweift erscheint, moechte ich der 
geneigten Leserschaft eine Bitte unterbreiten:

Und zwar, von allzu akademischen und theoretischen Betrachtungen Abstand 
zu nehmen und Vorschlaege zu machen, wie ich es eurer Meinung nach 
schaffen kann, eine uSD Karte mit ext4 (noatime) moeglichst schnell 
kaputtzuschreiben.

Die Algorithmen sollten wenn moeglich nahe am Nutzungsmuster eines Rpi 
liegen (naja, wie auch immer das aussehen mag). Bitte auch um ein paar 
Angaben, warum ihr glaubt, dass euer Algorithmus es am schnellsten 
schafft, die Karte totzukriegen. Ich habe natuerlich selbst auch schon 
eine Idee, will aber nicht vorgreifen oder beeinflussen.

Gerne greife ich das aussichtsreichste Verfahren auf, lasse es auf ein 
paar der uSD Karten aus dem Haufen hier neben mir los und poste dann die 
Ergebnisse.

Anschliessend habe ich vor, die gleichen Kartentypen nochmals mit f2fs 
mit den gleichen Algorithmen zu quaelen und wieder die Ergebenisse hier 
zu posten.

Karl schrieb:
> Irgendwo muss sich der Controller merken, wie oft er welche Blöcke
> beschrieben hat, und das ausfallsicher. Welchen Speicher nutzt er denn
> dafür, der muss ja mindestens so robust sein wie der Flash? Eeprom?

Er nutzt dazu den ohnehin vorhandenen Flash. Bei eMMC (technisch 
äquivalent zur SD-Karte) ist da auch die Firmware des Controllers drauf. 
Dazu gibt's einen Vortrag vom 34c3. Ein paar zig MB Größenunterschied 
bei verschiedenen 8 GB-Karten merkst du sowieso nicht.

B. R. schrieb:
> Wenn die Karte 8GB hat, die 8GB mit einem Filesystem belegt sind
> und das OS dem Controller nicht mitteilt, welche Sektoren keine
> Daten enthalten (siehe TRIM), wird es fuer den uSD Controller sehr
> schwer mit dem wear leveling.

Die Chancen stehen gut, dass auf deiner 8 GB-Karte insgesamt 16 GB-Flash 
verbaut sind, von denen ein gewisser Anteil schon ab Herstellung defekt 
ist. Wenn 10 GB zuerlässig arbeiten, hast du 2 GB an Reservesektoren 
(eine 10 GB-Karte lässt sich nicht verkaufen).

B. R. schrieb:
> Deshalb versuche ich herauszufinden, ob ein paar der Kartentypen, die
> ich ins Auge gefasst habe (weil das Preis/Leistungsverhaeltnis ungefaehr
> passt), ZUVERLAESSIG GENUG sind fuer die Verwendung im Rpi.

Da gelten noch andere Randbedingungen, wie z.B. das Verhalten bei 
Stromausfall ohne Entnahme. Bei Hot-Unplug hat der Controller genug 
Zeit, um die Daten wegzuschreiben (die Power-Pins sind länger), bei 
Stromausfall im Sockel nicht.

Die dann manchmal entstehenden Fehler sind für dich unvorhersehbar und 
werden nur von Dateisystemen mit Prüfsummencheck über Daten und 
Metadaten erkannt. Durch "wear-levelling durch den gesamten Flash" kann 
z.B. auch eine unbeteiligte, readonly gemountete Partition kaputtgehen. 
Darauf testest du z.B. auch nicht.

B. R. schrieb:
> Und zwar, von allzu akademischen und theoretischen Betrachtungen Abstand
> zu nehmen und Vorschlaege zu machen, wie ich es eurer Meinung nach
> schaffen kann, eine uSD Karte mit ext4 (noatime) moeglichst schnell
> kaputtzuschreiben.

a) Das Dateisystem maximal groß machen.
b) Die Testdatei maximal groß machen.
c) Die Testdatei mit einer Pseudozufallsfolge am Stück von vorn bis 
hinten beschreiben.
d) Die Testdatei am Stück auslesen und vergleichen.
e) Wiederhole c) und d) ad nauseam.

S. R. schrieb:
> a) Das Dateisystem maximal groß machen.
> b) Die Testdatei maximal groß machen.
> c) Die Testdatei mit einer Pseudozufallsfolge am Stück von vorn bis
> hinten beschreiben.
> d) Die Testdatei am Stück auslesen und vergleichen.
> e) Wiederhole c) und d) ad nauseam.
Das dürfte allerdings ewig dauern und stellt auch weider nicht das mehr 
oder weniger reale Problem dar, dass die Karten durch Datenbanken oder 
Logging aussteigen.

Das große problem ist noch immer ob mand avona usgehen kann, ob 
überhaupt Wear Leveling aktiv ist.
Dass die Micro-SD karten das inzwischen überhaupt haben, war mir neu!
Schön dass die Industrie das nicht mehr auf SSDs beschränkt.

S. R. schrieb:
> a) Das Dateisystem maximal groß machen.
> b) Die Testdatei maximal groß machen.
> c) Die Testdatei mit einer Pseudozufallsfolge am Stück von vorn bis
> hinten beschreiben.
> d) Die Testdatei am Stück auslesen und vergleichen.
> e) Wiederhole c) und d) ad nauseam.

Oder direkt auf das (raw) Block Device zugreifen.
- Einmal alle Blöcke beschreiben.
- Danach nur noch einen einzelnen Block schreiben (O_/SYNC, O_DIRECT 
oder per MMC), solange bis es zum I/O Fehler kommt.
- Verschiedene Karten anhand der Aanzahl der Writes bis zum Auftritt des 
Fehlers vergleichen

Wenn es darum geht die Karte schnellstmöglich zu zerstören: Während des 
Schreibzugriffs die Stromzufuhr kappen. Ein paar mal wiederholen. Lothar 
hat dazu ein paar Zahlen (wenn ich mich richtig erinnere).

Edit: Wenn es unbedingt mit ext4 sein muss, halt eine Datei anlegen, und 
bspw. immer wieder den ersten Block schreiben (O_/SYNC, O_DIRECT). 
Vorher das Filesystem natürlich einmal voll machen.

Alex G. schrieb:
> Das große problem ist noch immer ob mand avona usgehen kann, ob
> überhaupt Wear Leveling aktiv ist.

Davon kannst du ausgehen, denn ohne FTL (Flash Translation Layer) ist 
aktueller, großer NAND praktisch unbrauchbar. In den µSD-Karten stecken 
8051- oder ARM-Kerne dafür drin.

usuru schrieb:
> Im Armbian-Forum hat einer einen OrangePi (hat nur eine EXT4-Partion,
> keine FAT-Partition) mehr als 150x hart ausgeschaltet und die SD-Karte
> war immer noch nicht hinüber.

Er muss dabei auch einen Schreibzugriff unterbrechen und selbst dann ist 
nicht jede Karte dafür anfällig. Und er wird auch sicherlich nicht alle 
Datenblöcke nach jedem Hardreset auslesen, also stehen die Chancen gut, 
dass er Datenkorruption nicht bemerkt. Es können irgendwelche Bereiche 
betroffen sein, unabhängig von TRIM.

c-hater schrieb:
> Warum auch? Damit kannst du höchstens die logische Struktur der Daten
> beschädigen, aber nicht die Hardware.

Die Firmware des Controllers ist auch in dem Flash gespeichert, nicht im 
Controller.

c-hater schrieb:
> Warum auch? Damit kannst du höchstens die logische Struktur der Daten
> beschädigen, aber nicht die Hardware.
Jein, denn da fallen grade die Lebens-verlängernden Maßnahmen der 
Controler einem in den Rücken - fällt der Strom nämlich grade dann aus 
während irgendwas umkopiert oder umgeordnet wird, dann sind auch 
unbeteiligte Daten unter Umständen korumpiert und das können grade Daten 
sein welche das OS benötigt.
Oder noch schlimmer, es ist die Firmware des Controlers selbst!
Bei SSDs sind Fälle dokumentiert wo die SSD hinterher genau deswegen 
nicht mehr zugreifbar war. Als Nutzer kann man dazu schon sagen dass die 
Hardware "kaputt" ist.
Darum haben inzwischen mehr SSDs, Stützkondensatoren.

Denkbar wäre dass der Bananapi, auf dem Board mehr Stützkodnensatoren 
hat, als der Raspi.

Selbst hab ich auch noch keine SD Karte dadurch gebrickt obwohl ich gut 
einige dutzend mal, den Strom abgeschaltet hab.
Es ist aber ein Glücksspiel.


S. R. schrieb:
> Alex G. schrieb:
>> Das große problem ist noch immer ob mand avona usgehen kann, ob
>> überhaupt Wear Leveling aktiv ist.
>
> Davon kannst du ausgehen, denn ohne FTL (Flash Translation Layer) ist
> aktueller, großer NAND praktisch unbrauchbar. In den µSD-Karten stecken
> 8051- oder ARM-Kerne dafür drin.
Ganze ARM kerne in einer Micro SD?
Richtig faszinierend!

Jedenfalls gut zu wissen.

Mikro 7. schrieb:
> Hast du denn eine Quelle für deine gegenteilige Behauptung?
Bei "besseren" Karten kann man SMART Daten auslesen. Und dort sieht man, 
dass bei einer Karte, die zu 95% mit statischen Dateienn belegt ist, 
trotzdem alle Flashblöcke verwendet werden.

usuru schrieb:
> m Armbian-Forum hat einer einen OrangePi (hat nur eine EXT4-Partion,
> keine FAT-Partition) mehr als 150x hart ausgeschaltet
Das läuft für mich immer noch unter "Zufall"... ?

Bei meinem Dauerschreibtest werden gute SD Karten mindestens 15000 mal 
(also hundert mal mehr) ausgeschaltet. Die einzige Strategie, die 
zugrunde gelegt wird, ist, dass bei einem erkannten Powerfail kein neuer 
Schreibvorgang mehr gestartet wird und dass die Versorgung nach dem 
letzten Schreibbefehl noch mindestens 400ms gepuffert ist.

Ich denke das die Hersteller einen nicht komplett im Regen stehen lassen 
werden und schon ein paar Infos rausrücken.

Bei Sandisk wird ja die höchste Garantie bei den Sandisk Extreme Pro 
gegeben, man kann ja mal anfragen was die Extreme Pro von einer Ultra 
oder High Endurance unterscheidet irgendetwas müssen Sie ja schreiben.

Die High Endurance Karte ist ja für Videoaufzeichnungen gemacht, wo die 
Karte wieder und wieder überschrieben wird und hier werden alle Zellen 
gleichmäßig benutzt. Ein großartiges wearleveling wird hier nicht 
funktionieren, deswegen vermute ich sehr stark das hier qualitativ 
bessere SLC Speicherzellen zum Einsatz kommen, was die geringere 
Speicherkapazität erklären wurde.

Für die meisten SLC-Flashspeicher geben die Hersteller 100.000 Zyklen 
an, für MLC sind es nur zwischen 1000 und 3000.

Ich würde erstmal versuchen nur eine Zelle/Block wiederholt zu 
beschreiben, zur noch mit der kleinsten Kapazität damit der Test nicht 
so teuer ausfällt. Und danach eine möglichst große Karte des 
Siegermodels kaufen um den wear leveling hohe Chancen zu geben.

Oder eben von USB-SSD Platte zu starten hier kann man sich bewusst für 
SLC und gegen MLC und TLC entscheiden.

Thomas O. schrieb:
> Ich denke das die Hersteller einen nicht komplett im Regen stehen lassen
> werden und schon ein paar Infos rausrücken.
Vergiss es. Schon zu Zeiten von CompactFlash habe ich die aufgemacht, 
direkt am Write- und am Enable-Pin des Flashs gemessen und gesehen, dass 
einige CF noch gut 1s nach dem letzten Schreibbefehl an den Pins 
herumgezerrt haben. Da war dann nach längerem Nachbohren nur zu 
erfahren, dass das eben so sei....

> Ich würde erstmal versuchen nur eine Zelle/Block wiederholt zu
> beschreiben
Du hast überhaupt nicht die Wahl, von aussen eine definierte 
Speicherzelle des Flashs anzusprechen. Auch wenn du ständig von aussen 
den selben Block adressierst, wirst du immer wieder einen anderen 
Flash-Block bearbeiten, weil der Controller die Zugriffe ummappt.

Karl schrieb:
> Ich hab bereits 2 tote Samsung EVO
Ich habe inzwischen etwa 80 totgeschriebene microSD Karten Und kann da 
eben nur von denen berichten, die bei meinem Test positiv oder negativ 
auffallen.

Ich wäre auch daran interessiert wie du Smart ausliest (MMC,SDIO); sowie 
bei welchen Karten das geklappt hat und bei welchen nicht.

Lothar M. schrieb:
> Du hast überhaupt nicht die Wahl, von aussen eine definierte
> Speicherzelle des Flashs anzusprechen. Auch wenn du ständig von aussen
> den selben Block adressierst, wirst du immer wieder einen anderen
> Flash-Block bearbeiten, weil der Controller die Zugriffe ummappt.

Das denke ich aber schon,indem man nur einen Block frei läßt(rest 
vollmachen oder anderst partitionieren) und diesen immer wieder 
löscht/beschreibt. Ich denke nicht das die dann wirklich die Blöcke mit 
bereits verwendeten tauschen. Da würden die Schreibraten ja extremst 
einbrechen.

900ss D. schrieb:
> Also ich korrigiere meine Aussage insoweit, dass in SD-Karten nicht
> umkopiert wird. Um diesen Speicher geht es hier ja.

Hier ein Hersteller, der es macht. Damit wäre zumindest die Behauptung 
widerlegt, dass es kein Wear Leveling auf SD Karten gibt.

https://www.mouser.de/pdfdocs/S-45_fact_sheet1.pdf

In der Praxis bleibt es aber ein Problem herauszufinden, ob/welche Art 
von Waer Leveling implementiert ist, wenn man keine Spec. hat. Da könnte 
dann Smart ggf. einen Hinweis liefern.

Mikro 7. schrieb:
> Damit wäre zumindest die Behauptung widerlegt, dass es kein Wear
> Leveling auf SD Karten gibt.

Ich hab nirgends behauptet, dass es kein wear-leveling auf SD-Karten 
gibt. Im Gegenteil habe ich sogar beschrieben,  wie das funktioniert auf 
SD-Karten.
Was ich aber geschrieben habe ist folgendes:

900ss D. schrieb:
> Beim static Wear leveling werden tatsächlich Blöcke umkopiert. Findet
> aber in Sd-Karten eher nicht statt.

Und die SD-Karte, die du herausgesucht hast, gehört zu den seltenen 
Fällen, wo es sogar ein statisches wear-leveling gibt. Ja, ist aber sehr 
selten.
Und die von dir erwähnte Karte wäre für den Raspi sicher sehr gut 
geeignet. Ob sie beim ausschalten ohne "runterfahren" auch einen guten 
Schutz bietet,  ist weiter offen.

Das wäre doch mal ein Entwicklungsauftrag an diejenigen unter uns, die 
mit FPGAs & Co. unterwegs sind:

Nachbildung eines SDXC-Interfaces mit Umsetzung auf SATA-Host, so daß 
man eine SATA-Festplatte (oder -SSD) an einem SDXC-Karten-Slot betreiben 
kann.

Da die SD-Karte am Raspberry Pi nicht über USB angebunden ist (wie sonst 
eigentlich alles), würde diese Massenspeicheranbindung keine 
USB-Bandbreite verbrauchen.

https://www.micron.com/~/media/documents/products/technical-note/nand-flash/tn2942_nand_wear_leveling.pdf

soul e. schrieb:
> Auch Samsung und Sandisk haben seit dem white paper von 2003 ihre
> Algorithmen ein wenig weiterentwickelt.

Solange es kein Paper/Datenblatt gibt, wo beschrieben steht, dass sie 
static wear-leveling  betreiben, ist für mich auch keins drin. Nicht 
umsonst sind die Swissbit-Karten auch deutlich teurer.

c-hater schrieb:
> Das Problem sind die Seiten, in denen die internen
> Verwaltungsinformationen der Firmware stehen, nicht die, in denen die
> Firmware selbst steht.

Einverstanden. Ob die Karte nun aber nicht mehr funktioniert, weil die 
Firmware beschädigt ist oder wegen beschädigter Metadaten beim Start 
abstürzt, kann mir als Nutzer relativ egal sein.

Thomas O. schrieb:
> [immer nur eine Zelle/Block beschreiben geht nicht]
> Das denke ich aber schon,indem man nur einen Block frei läßt(rest
> vollmachen oder anderst partitionieren) und diesen immer wieder
> löscht/beschreibt.

Du glaubst, dass in einer 8 GB großen SD-Karte auch 8 GB Flash verbaut 
und (minus der Controllerfirmware) für den Nutzer bereitgestellt sind. 
Dem ist nicht immer so.

Bunnie (der sich ebenfalls mit SD-Karten beschäftigt hat) meinte mal in 
einem Vortrag, dass er in einer 128 MB großen SD-Karte sagenhafte 16 GB 
Flash gefunden hat. Der Rest war halt schon ab Werk defekt. Die Margen 
sind bei Flash so gering, dass jeder Baustein auch verwendet werden 
muss, egal welcher Qualität.

SDMI schrieb:
> Hm, hier (HP notebool) ist es eine PCI-to-X bridge:

Was hat das jetzt mit einem Raspberry Pi zu tun?

Karl schrieb:
> Wie willst Du das denn definieren? Datenlogger, NAS, Spielepi... da
> gibts doch die verschiedensten Muster.

In der Tat schwierig.

> Auch bei mySQL oder SQlite ist mir nicht klar: Wird da bei jedem Eintrag
> neu geschrieben? Oder wird erst geschrieben, wenn eine bestimmte Menge
> Daten zusammensind?

Das ist bei SQLite so, dass IMMER sofort geschrieben wird, wenn Du 
nichts spezielles machst (implizite Transaktion). Das kann sehr zaeh 
werden, wenn Du jeden einzelnen Record schreibst (auch bzw. gerade bei 
Festplatten).
Wenn Du 100 Schreibaufrufe in einer Transaktion buendelst, wird erst am 
Ende der Transaktion geschrieben.

WIE geschrieben wird, haengt vom Modus ab. Ich empfehle bzw. verwende 
WAL (https://www.sqlite.org/wal.html), das schreibt erst mal in ein Log. 
Das duerfte generell guenstiger sein fuer die Karte, unabhaengig vom 
Filesystem und hat noch ein paar weitere Vorteile (siehe Link).

> Am Kartenschonendsten finde ich hier die gute alte csv-Datei: Die Daten
> werden einmal geschrieben und dann nicht wieder angefasst. Neue Daten
> werden nur ans Ende angefügt und für den nächsten Tag / Monat... wird
> eine neue Datei angelegt.

Gewiss, ich bin sowieso ein Fan von Textdateien. Nur benoetigt man 
oftmals doch eine Datenbank, z.B. SQLite.

> Oder halt Round-Robin in einer Ramdisk und regelmäßig die Daten
> exportieren. Aber die exportierten Daten dann in Ruhe lassen.

Dann hast Du aber ein Problem, wenn Du Stromausfaelle nicht 
ausschliessen kannst.

Ich versuche mit der ganzen Aktion in der Praxis (!!) folgendes 
herauszufinden:

1) Welche Karten sind besser und welche schlechter?
2) Ist ext4 fuer Dauerbetrieb gut genug?
3) Ist f2fs besser und, vor allem, ext4 vorzuziehen?

Rufus Τ. F. schrieb:
> Da die SD-Karte am Raspberry Pi nicht über USB angebunden ist (wie sonst
> eigentlich alles), würde diese Massenspeicheranbindung keine
> USB-Bandbreite verbrauchen.

Leider ist die Rpi SD-Schnittstelle etwas lahm, soweit ich weiss auch 
beim Raspi3 nicht wesentlich ueber 20MB/s hinaus.

S. R. schrieb:
> Bunnie (der sich ebenfalls mit SD-Karten beschäftigt hat) meinte mal in
> einem Vortrag, dass er in einer 128 MB großen SD-Karte sagenhafte 16 GB
> Flash gefunden hat. Der Rest war halt schon ab Werk defekt. Die Margen
> sind bei Flash so gering, dass jeder Baustein auch verwendet werden
> muss, egal welcher Qualität.

Das ist ganz sicher so. Aber der zusaetzliche Speicher ist ja defekt und 
kann auch vom Controller nicht genutzt werden. Ausser bei 
China-Fake-Karten ;-)

B. R. schrieb:
> 1) Welche Karten sind besser und welche schlechter?

Der vermutlich einzige hier mit handfesten Daten ist Lothar und seine 
Erfahrungen findest du weiter oben sowie in anderen Threads zum Thema.

Allerdings darf ein Hersteller den Controller und die Algorithmen 
jederzeit wechseln, und das sieht man den Karten im Laden auch nicht an. 
Vermutlich nichtmal im Großhandel.

Wie du an der Diskussion auch erkennen kannst, gibt es keine "ultimativ 
guten Karten", sondern nur Stichproben, anekdotische Erfahrungswerte, 
Vermutungen und allgemeines Wissen über die Möglichkeiten der 
Hersteller. Wie die Karte für dich performt, hängt schlussendlich 
ausschließlich von deinem Anwendungsfall ab.

> 2) Ist ext4 fuer Dauerbetrieb gut genug?

Eine eMMC unterscheidet sich technisch nicht wesentlich von einer 
SD-Karte, also gehe ich schlicht mal davon aus, dass da auch die gleiche 
Technik drin steckt.

In Android-Geräten wird fast durch die Bank weg ext4 verwendet und (wenn 
ich mich recht entsinne) ist das auch eine Empfehlung von Google. Du 
kannst also davon ausgehen, dass ext4 gut genug funktionieren wird. Es 
ist sehr gut getestet, äußerst stabil und sehr robust gegenüber 
Datenfehlern.

> 3) Ist f2fs besser und, vor allem, ext4 vorzuziehen?

Ich habe f2fs mal angetestet und habe keine schwerwiegenden Probleme 
festgestellt. Einige Android-Geräte nutzen das auf ihren internen eMMCs, 
also wird auch das funktionieren.

Die Performance verglichen mit ext4 dürfte je nach Anwendungsfall bei 
"geringfügig mehr" bis "deutlich weniger" liegen, da ext4 meines Wissen 
nirgends komplett versagt. Auf einem Raspberry kann dir das aber ohnehin 
egal sein, weil die Schnittstelle ohnehin langsam ist.

Andererseits ist f2fs m.W. weniger robust gegenüber Datenkorruption, 
d.h. wenn die SD-Karte was kaputt macht, dann hast du geringere Chancen, 
an die Daten noch ranzukommen. Im Zweifelsfall gibt dir der Mountversuch 
eine Kernel Panic.

Das wäre für mich der wichtigere Punkt: SD-Karten sind in meiner 
Wahrnehmung schlicht unzuverlässig und ext4 kann da möglicherweise noch 
mehr retten als f2fs. Daher würde ich auf ext4 setzen, wenn es nicht 
gerade um Spielereien (oder den letzten Rest an Performance) geht.

B. R. schrieb:
> Aber der zusaetzliche Speicher ist ja defekt und kann auch vom
> Controller nicht genutzt werden. Ausser bei China-Fake-Karten ;-)

SD-Karten werden nur in Standardgrößen verkauft (ungefähre 
Zweierpotenzen). Wenn von dem verbauten Flash also nur 6 GB einigermaßen 
zuverlässig sind, würde ich davon ausgehen, dass die Karte als "4 GB" in 
den Handel kommt und 2 GB an Reservesektoren fürs Wear-Levelling 
enthält.

S. R. schrieb:

> sondern nur Stichproben, anekdotische Erfahrungswerte,

Deshalb habe ich erst mal meine eigenen Performancetests gemacht 
(Beitrag "Re: zuverlässige SD-Karte für Raspberry Pi") mit 
durchaus stark unterschiedlichen Ergebnissen zwischen einzelnen Typen.

Momentan mache ich einen Zuverlaessigkeitstest mit einigen der Karten, 
die ich ausgehend von den Performancetests in die engere Wahl genommen 
habe.

Jedenfalls ist richtig, dass die Aussagekraft solcher Tests zum einen 
nur auf exakt das gleiche Modell gilt (siehe z.B. die eklatanten 
Unterschiede oben zwischen einer "Samsung Evo+ 32GB" und dem "besseren" 
Nachfolger "Samsung Evo plus 32GB").

Zum anderen sollte man selbst bei exakt gleicher Type die Tests in 
gewissen Intervallen bei einer neuen Charge wiederholen, weil niemand 
garantiert, dass nicht doch etwas innerhalb der gleichen Type geaendert 
wird. Erschwerend kommt hinzu, dass solche moeglichen Aenderungen immer 
auf den urspruenglichen Anwendungszweck abzielen ("Fotoapparat") und 
vielleicht im Raspi massivere Auswirkungen haben.

> Die Performance verglichen mit ext4 dürfte je nach Anwendungsfall bei
> "geringfügig mehr" bis "deutlich weniger" liegen, da ext4 meines Wissen
> nirgends komplett versagt. Auf einem Raspberry kann dir das aber ohnehin
> egal sein, weil die Schnittstelle ohnehin langsam ist.

Laut meinen Tests ist die Leseperformance fast identisch, die 
Schreibperformance gerade bei kleinen random Zugriffen (und genau diese 
sind beim Raspi massgeblich, noch staerker bei einer DB-Anwendung) um 
Faktoren hoeher (EurEx ist Preis exkl. MwSt, Datenraten in MByte/s):

1

flashbench Raspi3 f2fs  |Typ|Typennummer       |EurEx|RSEQ|WSEQ|RRND|WRND

2

------------------------+---+------------------+-----+----+----+----+----

3

Sandisk Extreme 32GB V30|uSD|SDSQXAF-032G-GN6MA| 16.0|19.7|19.2| 9.0|19.0

4

Transcend Ult. 600x 8GB |uSD|TS8GUSDHC10U1     |  6.5|21.5|13.1| 5.7|13.5

5

Adata Premier 8GB       |uSD|AUSDH8GUICL10     |  6.8|17.8| 7.5| 6.0| 8.7

6

xlyne SDHC 8GB          |uSD|7408001           |  5.4|14.3|10.9| 4.4| 8.0

7

8

flashbench Raspi3 ext4  |Typ|Typennummer       |EurEx|RSEQ|WSEQ|RRND|WRND

9

------------------------+---+------------------+-----+----+----+----+----

10

Sandisk Extreme 32GB V30|uSD|SDSQXAF-032G-GN6MA| 16.0|21.9|20.6| 9.3| 6.8

11

Transcend Ult. 600x 8GB |uSD|TS8GUSDHC10U1     |  6.5|21.5|14.5| 5.9| 1.4

12

Adata Premier 16GB      |uSD|AUSDH16GUICL10-R  |  6.8|21.6| 9.8| 5.6| 1.5

13

xlyne 8GB               |uSD|7408001           |  5.4|19.5|11.5| 4.4| 1.4

Wenn Geld keine Rolle spielt bzw. man die maximale Performance bzw. 
Platz braucht, wuerde ich erst mal zur Sandisk Extreme 32GB V30 
(SDSQXAF-032G-GN6MA) raten, sonst zur Transcend Ultimate 600x 8GB 
(TS8GUSDHC10U1). Jedenfalls werde ich das so machen.

> Andererseits ist f2fs m.W. weniger robust gegenüber Datenkorruption,

Das glaube ich eher nicht. Insbesondere geht das f2fs schonender mit dem 
FLASH um (das teste ich ja gerade). Siehe auch 
https://www.usenix.org/system/files/conference/fast15/fast15-paper-lee.pdf.
Und das f2fs ist ganz speziell auf FLASH ausgelegt, was das ext4 
definitiv nicht ist.

Ich denke daher, dass das f2fs die bessere Alternative fuer die 
Anwendung "uSD im Raspi" ist und werde es selbst auch verwenden.
Das werden erst mal ca. 50 Geraete sein sein mit einer SQLite bzw. 
MariaDB Anwendung drauf mit nicht unerheblichen Datenmengen. Gerne 
berichte ich in etwa einem Jahr hier, wie sich das f2fs geschlagen hat.

> SD-Karten werden nur in Standardgrößen verkauft (ungefähre
> Zweierpotenzen). Wenn von dem verbauten Flash also nur 6 GB einigermaßen
> zuverlässig sind, würde ich davon ausgehen, dass die Karte als "4 GB" in
> den Handel kommt und 2 GB an Reservesektoren fürs Wear-Levelling
> enthält.

So wird das wohl gemacht, ja.

Lothar M. schrieb:

> Dieser Dauerschreibtest läuft nun mit unterschiedlichen Karten seit ca.
> 3 Jahren und er wird auch die nächsten Jahre noch weiterlaufen.

Ich weiss, schon etwas spaet, aber eventuell liest Du ja trotzdem:

Moechtest Du nicht mitteilen, welche Karten Du im Test hast und wie der 
Algorithmus Deines Dauerschreibtests aussieht?

SDMI schrieb:
> Dann mal bitte: Butter => Fische!
Ich habe schon seit dem 
Beitrag "Re: zuverlässige SD-Karte für Raspberry Pi" und lange vorher 
Butter an die Fische getan. Ich will mich nicht wiederholen... ;-)

B. R. schrieb:
> Moechtest Du nicht mitteilen, welche Karten Du im Test hast
ATP, Kingston, Samsung, SanDisk, Swissbit, Toshiba, Innodisk und die 
XMore (und noch einige der ganz billigen TLC-Consumer-Karten, aber die 
flogen alle schon nach kürzester Zeit, also ein paar Stunden oder 
wenigen Tagen aus dem Test).

> und wie der Algorithmus Deines Dauerschreibtests aussieht?
1. Vorbereitung: Karte mit FAT32 formatiert und
  Karte zu 95% mit statischen Daten gefüllt

2. Ablauf
- Einschalten und Start von dieser Karte

- 300s lang laufendes Schreiben der selben Datei
  mit 50kByte Größe und sich ändernden Werten

- Abschalten der Versorgung
  bei Erkennung des Powerfails wird kein neuer Schreibvorgang mehr 
gestartet,
  die Versorgungspannung liegt noch 500ms nach erkanntem Powerfail an

- 15s Aus, dann von vorn

3. die Karte wird dann regelmäßig (derzeit 1x pro Woche, wenn beim 
Booten und Betrieb keine Auffälligkeiten zu sehen sind) entnommen, die 
statischen Daten manuell auf Veränderungen geprüft und die SMART-Daten 
protokolliert

Die SMART-Daten einer XMore Karte, die seit Mai letzten Jahres im Test 
ist, sehen aktuell so aus:

1

 1. Maker Information             : pSLC

2

 2. WearSel Type                  : Embedded

3

 3. Endurance Life Ratio          : 0.00%

4

 4. Good Block Ratio              : 98.60%

5

 5. F/W ECC BIT Setting           : 42

6

 6. Total Refresh Count           : 0

7

 7. Total Power Up Count          : 84633

8

 8. Abnormal Power On Count       : 0

9

 9. Erase Count :       Average   : 37584

10

                       Maximum    : 37752

11

                    Total Number  : 37810363

12

                 Erase Endurance  : 20000

13

10. Maximum Block Replace Number  : 48

14

11. Scan Bad Block                : 30

15

      DIE  : Early Bad  : Later Bad

16

      0    : 30         : 0

Dort sieht man, dass ein besonderer "Embedded" Wearlevel-Algorithmus 
zugange ist (siehe meine früheren Beiträge). Die Restlebenszeit ist 
0,00% (schon seit Mitte Oktober), weil jeder Block schon 37k mal 
gelöscht wurde, obwohl er nur für 20k spezifiziert ist. Und dass nach 
85k Einschaltvorgängen zu den anfänglich defekten 30 defekten Blocks 
noch kein neuer dazugekommen ist.

Lothar M. schrieb:
> dass ein besonderer "Embedded" Wearlevel-Algorithmus

Das Datenblatt was man dazu bei Distrelec runterladen kann sagt, dass es 
static- und dynamic-wear-leveling in den Karten gibt. Also von einem 
speziellen "embedded" Algorithmus habe ich noch nicht gehört.

Hexen können die ja auch nicht ;)

Und richtig teuer sind die XMore-Karten. Da ist die Swissbit ja ein 
Schnäppchen :)

MMC schrieb:
> Antworten denn die XMore Karten auch auf:
> mmc extcsd read /dev/mmcblk0 ?
Das musst du selber ausprobieren.
Den Befehl gibt es bei dem von mir verwendeten OS nicht  ;-)

900ss D. schrieb:
> von einem speziellen "embedded" Algorithmus habe ich noch nicht gehört.
Ja, du hast den Trick erfasst: weil das Ganze sowieso 
herstellerspezifisch ist kann der seinen Werlevel-Algorithmus nennen wie 
er gerne will. Wie schon wiederholt gesagt: du bekommst normalerweise 
die Karte SDU008GXPS8C016 mit Z am Ende:
https://www.glynshop.com/erp/owweb/Daten/Datenblaetter/DRAM_FLASH_MEDIEN/03_SD/02_Xmore/microSD/pSLC/15nm/Xmore%20professional%20SDUxxxxXPx8x016Z%20v2.5.pdf
Auf Nachfragen und bei speziellen Problemen gibt es aber auch andere 
Wearlevel-Algorithmen. Und dann kommt z.B. ein E ans Ende...

People for the Ethical Treatment of SD Cards schrieb im Beitrag 
#5290189:
> So eine Woche bei 0,0V und 60-85°C währen interessant.
Diesen Test zum Thema "Datenerhalt" durchlaufen gerade ein paar 
Geschwister der Karte...  ;-)

Ich habe mir zunaechst mal die "xlyne SDHC 8GB (740800)" und die 
"Transcend Ultimate 600x 8GB (TS8GUSDHC10U1)" vorgeknoepft und einen 
"Kaputtschreibtest" auf einem Raspberry Pi 3 durchgefuehrt.

Die Aufteilung der SD-Karten war bei Nr. 1 und 2 (siehe unten) eine 5GB 
Datenpartition und eine 2.7GB leere Partition, jeweils mit dem 
entsprechenden Filesystem formatiert (das Raspbian war auf einem 
USB-Stick, von dem gebootet und von dem auch das Testprogramm gestartet 
wurde).

Weil das meinem spaeteren Anwendungsfall eher entspricht, bin ich fuer 
Test Nr. 3 dazu uebergegangen, eine 3.7GB Raspbian-Partition mit dem 
Testprogramm drauf (ca. 70% gefuellt) und eine 3.7GB Datenpartition fuer 
die Schreibtestdatei zu erzeugen.

Der Testalgorithmus laeuft wie folgt:

A) Testdatei erzeugen/oeffnen mit O_SYNC|O_DIRECT (Posix open)
B) Abwechselnd mit je 1MByte 0x55 und 0xAA beschreiben (offset 0, Posix 
write)
C) Nach jedem schreiben wieder zuruecklesen/pruefen (Posix read)

Mounten bei ext4 mit "noatime,nodiscard" und f2fs mit "noatime" 
(nodiscard gibts hier nicht).

1

 Nr | uSD                         | fs | TB | MB/s 

2

----+-----------------------------+----+----+-----

3

  1 | xlyne 8GB 7408001           |ext4| 1.3|  3.4 

4

  2 | xlyne 8GB 7408001           |f2fs| 1.3|  8.0 

5

  3 | Transcend 8GB TS8GUSDHC10U1 |f2fs| 5.5|  8.0

Spalte "TB" sind die Terabyte, die insgesamt geschrieben bzw. 
ueberschrieben wurden. Spalte "MB/s" ist die erzielte mittlere Datenrate 
in MByte pro Sekunde (schreiben inkl. zuruecklesen und pruefen).

Die beiden uSD Karten zeigten soweit keinerlei Datenfehler oder andere 
"Abnuetzungserscheinungen" (z.B. sank die Datenrate gegen Ende NICHT, 
auch nicht beim ext4 Test).

In den naechsten Monaten werde ich den Schreibtest so weit treiben, bis 
die uSD Karten kaputt sind. Angesichts der bisherigen Ergebnisse duerfte 
das aber noch einige Zeit in Anspruch nehmen.

Zwischenzeitlich werde ich mir noch die Sandisk Extreme 32GB 
(SDSQXAF-032G-GN6MA) vornehmen.

Interessant!
Denke weiter totschreiben bringt nichts, das ist ja schon weitab 
jeglicher realer Nutzung.

Viel interessanter wäre da doch der Abschalt-Test!

> Denke weiter totschreiben bringt nichts, das ist ja schon weitab
> jeglicher realer Nutzung.

Es waere trotzdem interessant zu erfahren, wann die Teile WIRKLICH 
sterben. Dass die ueberhaupt solange gehalten haben (5TB mit der recht 
preiswerten Transcend bisher, das ist schon mal eine Ansage) fuehre ich 
grossteils auf das f2fs zurueck, weil das im Prinzip ja "perfektes" wear 
leveling betreibt.

> Viel interessanter wäre da doch der Abschalt-Test!

Das mache ich noch. Ich denke, folgende Vorgehensweise waere sinnvoll:

1) Schreiben mit dem gleichen Testprogramm wie oben (also eine 1MB Datei 
abwechselnd mit 0x55 und 0xAA beschreiben)
2) Versorgung kappen
3) Versorgung wieder dran und booten
4) Pruefen, ob der RPI3 ueberhaupt hochkommt, ob es irgendwelche 
Fehlermeldungen/Probleme gibt und wie die Testdatei aussieht.

Vielleicht das ganze so 25-50x wiederholen.
Mal sehen ob ich das irgendwie automatisieren kann, sonst wird das 
muehsam.

B. R. schrieb:
> grossteils auf das f2fs zurueck

Das hilft bei SD-Karten mit eigenem Wear-leveling überhaut nicht.
f2fs hilft, wenn du mit den Blocknummern von diesem dann direkt auch 
diese Blöcke ansprechen kannst. Also quasi raw-NAND-Zugriff hast.

Wenn aber ein SD-Karten wear-leveling dazwischen geschaltet ist, dann 
werden die Blocknummern verändert. Da kannst du dann soviel f2fs nehmen 
wie du möchtest.

Da bin ich ganz anderer Meinung.

Das wear-leveling der uSD-Karte schlaegt nur dann zu, wenn sich durch 
das Schreibmuster ergibt, dass ein physikalischer (!!) Sektor mehrfach 
beschrieben wird. Alles andere waere wenig sinnvoll und/oder zuviel 
Aufwand bzw. traue ich sowas den uSD Controllern gar nicht zu.

Selbst wenn diese Annahmen nicht zutreffen, ist es ein Vorteil, f2fs 
statt ext4 zu verwenden statt ext4, hauptsaechlich wegen der 
Log-Struktur (das zeigen bisher auch alle meine Testdaten).

Und es ist generell keine gute Idee, sich auf irgendwelche uSD internen 
wear-leveling Algorithmen, so sie denn ueberhaupt vorhanden sind, zu 
verlassen, und zwar aus mindestens 2 Gruenden:

1) Man weiss nie, ob ueberhaupt welche implementiert sind und falls sie 
das sind, wie die Algorithmen aufgebaut sind.
2) uSD Karten sind auf i.d.R. auf FAT optimiert und auf den Einsatz in 
einem Fotoapparat oder aehnlichem, nicht auf Raspis mit ext4.

Mir geht es bei dem Test nur darum, zu erfahren, wie gut ausgewaehlte 
uSD Karten mit f2fs massives (ueber-) schreiben wegestecken. Ob das nun 
auf die Karte, das FS oder auf beides zurueckzufuehren ist, ist mir 
egal.

B. R. schrieb:
> Das wear-leveling der uSD-Karte schlaegt nur dann zu, wenn sich durch
> das Schreibmuster ergibt, dass ein physikalischer (!!) Sektor mehrfach
> beschrieben wird.

Die wear-leveling Algorithmen, die ich kenne, machen das nicht so. Es 
wird IMMER ein Block nach dem Algorithmus ermittelt, nicht nur, wenn 
einer mehrfach hintereinander beschrieben wird.

B. R. schrieb:
> Und es ist generell keine gute Idee, sich auf irgendwelche uSD internen
> wear-leveling Algorithmen, so sie denn ueberhaupt vorhanden sind, zu
> verlassen, und zwar aus mindestens 2 Gruenden:

Wenn ein interner Algorithmus vorhanden ist, dann hast du keine Wahl. 
Wie willst du verhindern, dass die von dir vorgegebene Blocknummer durch 
einen einen internen waer-leveling Algorithmus verändert wird? Dadurch 
dann dein Algorithmus völlig außer Kraft gesetzt wird? Daran kommst du 
nicht vorbei.

Mag sein, dass die Karten FAT optimiert sind. Dann wäre es am besten, du 
nimmst FAT und nicht etwas anders.

Wenn dein Test eine Aussage haben soll, must du f2fs und ext4 gegen FAT 
bei verschiedenen Karten (Hersteller) antreten lassen. Und dass mit 
mehreren Karten. Einmal ist keinmal.