mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik zuverlässige SD-Karte für Raspberry Pi


Autor: Phil (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

kann jemand eine besonders zuverlässig SD-Karte für den Raspberry Pi 
(3B) empfehlen?

Ich habe mal gehört, dass es wohl früher Probleme mit einigen Karten und 
dem Raspberry Pi gab, darum habe ich das bisher immer gleich als Bundle 
gekauft. Galt das mit den Problemen nur für den ersten Raspberry Pi oder 
ist das immer noch so?

Ich möchte auf dem Pi ein Linux mit Webserver und MySQL laufen lassen. 
Es läuft eine Anwendung die bei einer Sportveranstaltung Zeiten 
entgegennimmt und diese auf Zeitenmonitoren darstellt sowie auch später 
die Auswertung macht.

Es wäre extrem blöd, wenn der Pi während der laufenden Veranstaltung 
ausfällt und diese sich dadurch verzögert. (Daten gingen keine verloren, 
diese Werten zur Sicherheit live gedruckt.)

Während des Betriebs wird ständig etwas in die Datenbank geschrieben 
(Zwischenzeiten usw. keine großen Datenmengen). Ich mache mir daher ein 
wenig Sorgen das ganze von der SD-Karte laufen zu lassen. Oder ist das 
heutzutage unbegründet?

Und ist es ggf. sinnvoll eine große Speicherkarte zu kaufen (zB. 64GB 
oder 128GB) und diese trotzdem nur mit einem kleinen partionierten 
Bereich zu verwendeten (einige GB) um viel Speicher für das Wear 
leveling über zu haben?

Vielen Dank für eure Hinweise

Autor: Harry L. (mysth)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Wolfgang (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Phil schrieb:
> Es wäre extrem blöd, wenn der Pi während der laufenden Veranstaltung
> ausfällt und diese sich dadurch verzögert.

Dann lass zwei oder besser drei Systeme parallel laufen, so dass du im 
Zweifelsfall bei Ausfall von einem System
1) trotzdem über (mindestens) eines mit gültigen Daten verfügst
2) weisst, welches ausgefallen ist bzw. Mist baut.

Dann kannst du im Fehlerfall schnell und einfach auf ein 
funktionierendes System wechseln.

Autor: Steffen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Harry L. schrieb:
> Boote von SD un pack das gesamte root-FS auf eine USB-Disk!

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

Wolfgang schrieb:
> Dann lass zwei oder besser drei Systeme parallel laufen,

Das wäre deutlich zu viel Aufwand.

Autor: Konrad S. (maybee)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Kai A. (kaiand1) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Wolfgang (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Steffen schrieb:
> Das wäre deutlich zu viel Aufwand.

k.A. welche Wichtigkeit das System hat, aber ein Raspberry Pi ohne 
Schnickschnack mit manuellem Umstecken der Anzeigeeinheit kostet nun 
wirklich nicht die Welt. Vermutlich kann der Nutzer die Daten recht gut 
plausibilisieren, so dass zwei parallel laufende Systeme ausreichen 
dürften, wenn die Umschaltung nicht automatisiert werden muss.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Konrad S. schrieb:
> 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.

Genau das kann ich auch bestätigen. Habe da mal detaillierte Messungen 
mit eigenem Treiber gemacht.

Autor: Phil (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wolfgang schrieb:
> k.A. welche Wichtigkeit das System hat, aber ein Raspberry Pi ohne
> Schnickschnack mit manuellem Umstecken der Anzeigeeinheit kostet nun
> wirklich nicht die Welt. Vermutlich kann der Nutzer die Daten recht gut
> plausibilisieren, so dass zwei parallel laufende Systeme ausreichen
> dürften, wenn die Umschaltung nicht automatisiert werden muss.

Es hängt alles über Ethernet am Pi. Also Anzeigeeinheiten sind andere 
Rechner an denen Monitore hängen. Da gibt es sicher Lösungen mit Linux, 
die dann beim Ausfall IP -Adresse usw vom ausgefallenen Rechner 
übernehmen können. Ich denke aber, wenn etwas ausfällt wird es wohl die 
SD-Karte sein. Wenn es nur das Netzteil oder so ist, dann kann man 
ohnehin einfach umstecken.
Die Daten zu plausibilisieren ist kein Problem. Die Zeiterfassung druckt 
es wie gesagt live aus (kleine Rolle wie an diesen Tischtaschenrechnern) 
und schickt die Daten nur zusätzlich an den Pi.


Hat jemand denn eine Idee, ob es etwas bringt die Karte vom Volumen 
größer zu dimensionieren als nötig, um Platz für das Wear leveling zu 
haben? Oder sind kleine Karten ggf. sogar robuster? Ich habe auch etwas 
von Industriekarten gelesen die weniger Datendichte haben und 
zuverlässiger sein sollen.

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Phil schrieb:
> Hat jemand denn eine Idee, ob es etwas bringt die Karte vom Volumen
> größer zu dimensionieren als nötig, um Platz für das Wear leveling zu
> haben?

Solange du nicht die Partition verkleinerst... das wear leveling kann am 
besten Arbeiten wenn die Karte wie in der Spezifikation vorgeschrieben 
formatiert wird, nämlich mit FAT16/FAT32/exFAT bei SDSC/SDHC/SDXC, und 
auch nur mit dem Tool von sdcard.org weil das die vorgegebenen Abstände 
einhält. Wie Linux mit einem solchen FAT als Haupt-Dateisystem klar 
kommt weiß ich aber nicht.

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Phil schrieb:

> kann jemand eine besonders zuverlässig SD-Karte für den Raspberry Pi
> (3B) empfehlen?

Gibt es nicht. Das liegt daran, dass beim RasPi die SD-Karte "völlig 
ungewöhnlich" benutzt wird. Eben nicht mit der vom 
SD-Verbrecher-Konsortium vorgegebenen Formatierung. Das führt dazu, dass 
sich die Schwächen dieses auf *Hauptsache billich, aber DRM-Gängelung 
muss schon sein* getrimmten Standards extrem schnell zeigen.

Abhilfe? Nur mittels SD-Karte völlig unmöglich!

Was aber geht: SD-Karte nur für's Boot-Image benutzen (eigentlich: für 
beide Boot-Images, das des SoC und das des Linux-Kernels ggf. samt 
initrd), das root-Filesystem aber auf eine via USB angekoppelte richtige 
SSD oder notfalls auch mech. HD packen.

Dann wird die SD-Karte nämlich nach dem einmaligen Beschreiben nur noch 
RO betrieben. Das kann sie seeehr lange ab.

Und nein: USB-Stick für's root-Filesystem ist praktisch genauso Scheisse 
wie SD-Card. Ebenfalls schnelles Ableben quasi vorprogrammiert. 
USB-Sticks taugen heutzutage genausowenig für ernsthafte Anwendungen wie 
SD-Karten.

Diese billigen Flashmedien sind allesamt designed wie Klopapier: am 
Besten nur einmal zu benutzen, alles darüber hinaus stinkt und klebt an 
den Fingern...

Autor: Alex G. (dragongamer)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
@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-Cir...
Wobei ich leider nicht weiss was Panasonic wohl mit "SLC Lite" meint.

: Bearbeitet durch User
Autor: Harry L. (mysth)
Datum:

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

Ich meine eine richtige Festplatte

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

: Bearbeitet durch Moderator
Autor: Alex G. (dragongamer)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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!

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Alex G. (dragongamer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: c-hater (Gast)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
Alex G. schrieb:

> Hast du dazu auch eine echte Quelle?

ICH bin hier die "echte Quelle". Das sind einfach Erfahrungen aus der 
Praxis. (und zwar nicht nur im Zshg. mit dem RasPi, sondern ganz 
generell mit der Benutzung dieser Medien als OS-Root, das betrifft sogar 
auch Windows auf FAT, was eigentlich aus Sicht des SD-Konsortiums völlig 
problemlos sein sollte!).

Glaub' es oder glaub' es nicht. Ist mir völlig Banane. Es steht jedem 
frei, seine schlechten Erfahrungen höchstselbst zu machen...

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch Moderator
Autor: wendelsberg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Beitrag #5160972 wurde von einem Moderator gelöscht.
Autor: Alex G. (dragongamer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

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

: Bearbeitet durch Moderator
Autor: Alex G. (dragongamer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)?

: Bearbeitet durch User
Autor: Phil (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ruhig Blut, Jungs ;)

Ich möchte nicht, dass der Thread geschlossen werden muss. Bisher kam 
hier ja sehr viel nützliches für das Projekt. Danke dafür!

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

Autor: Alex G. (dragongamer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Beitrag #5160997 wurde von einem Moderator gelöscht.
Beitrag #5160998 wurde von einem Moderator gelöscht.
Autor: Guido L. (guidol1970)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Phil (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex G. schrieb:
> 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.

Größenmässig wäre eine 2,5" SSD überhaupt kein Problem. Bisher läuft es 
alles auf meinem Notebook. Ich hätte einfach gerne etwas dediziertes 
dafür, dass man nicht jedes Mal neu einrichten muss.
Einziger Haken hierbei ist, das man ein wenig mehr Basteln muss als ein 
fertiges Linux Image auf die SD Karte zu schreiben. Aber die Hürde würde 
ich mal als sehr klein ansehen.

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.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alex G. (dragongamer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Phil (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Für Backups bzw. allgemeines Verwaltungsgedöns ist SQLite vermutlich
> besser geeignet als MySQL

Ich kenne SQLite leider fast nur vom Namen. Kann es denn das was MySQL 
kann? Ich verwende schon Trigger, Views usw. Und die Query verwenden 
natürlich Joins und was man halt in SQL so macht.

Alex G. schrieb:
> Daher bin ich mal davon ausgegangen, es sei keine Speicherung nötig.

Ich wollte damit eher vermeiden, dass es in eine Richtung läuft mit 
extremer Redundanz. Die Daten KÖNNTEN gerettet werden bei einem Ausfall, 
aber es wäre schon echt blöd und würde viel verzögern.

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. Zusätzlich kann man ja eine zweite SD-Karte einpacken die eine 
Kopie der ersten ist. Dann sollte man die Daten sehr schnell einspielen 
können.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: wendelsberg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Phil schrieb:
> 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.

Nicht wenn der Rasp... gleich direkt bei sich einen Pufferakku hat.

Ausserdem: Wenn der Kabelstolperer im unrechten Moment kommt, sind ja 
auf der SD nicht nur die letzten Daten kaputt, sondern unter Umstaenden 
die ganze DB.

wendelsberg

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Schreiber (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Phil schrieb:
> Während des Betriebs wird ständig etwas in die Datenbank geschrieben
> (Zwischenzeiten usw. keine großen Datenmengen). Ich mache mir daher ein
> wenig Sorgen das ganze von der SD-Karte laufen zu lassen. Oder ist das
> heutzutage unbegründet?

Erfahrungsgemäß gibt es keine Probleme, sofern man nicht gerade die 
allerbilligste SD-Karte aus dem Sonderangebot von Chinaman verwendet.

Bei allem was nicht gerade Bundesliega ist, würde ich mir bei 
Vereinsveranstaltungen keine Sorgen machen.

Phil schrieb:
> Es wäre extrem blöd, wenn der Pi während der laufenden Veranstaltung
> ausfällt und diese sich dadurch verzögert. (Daten gingen keine verloren,
> diese Werten zur Sicherheit live gedruckt.)

Ersatz-PI bereitlegen und daran denken, dass auch andere Teile 
(Tastatur, Monitor, Stromversorgung...) ausfallen können.

Autor: Phil (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Bei SQLite reicht es, die Datei zu kopieren, bei richtigen Datenbanken
> wie MySQL ist das nicht so einfach (die sind auf Dateiebene nicht
> konsistent).

Ich würde einfach mysqldump verwenden und keine Dateien kopieren.

S. R. schrieb:
> SQLite ist eine vollwertige SQL-Datenbank,

Dann ist das wohl mal einen Blick wert. Danke für den Hinweis.

Autor: Konrad S. (maybee)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guido L. schrieb:
> "Samsung EVO(+)"

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

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Der Knackpunkt bei solchen Produktempfehlungen ist: Erst nach vielen 
Monaten guter Erfahrung kann man eine Empfehlung aussprechen. Bis dahin 
ist das Produkt aber nicht mehr im Handel.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Du kannst dein Linux auch komplett aus einer Ramdisk betreiben

Dafür bräuchter der kleine Computer allerdings mehr RAM.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ein komplettes Ubuntu kriegt man da nicht rein

Das meine ich. Mit Abspecken kann man da sicher was machen. Ich hatte 
früher mal ein Minimalsystem mit X11 auf 8MB reduziert, aber das war 
schon ziemlich Umständlich.

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:

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

Es geschehen noch Zeichen und Wunder... Dass wir beide mal einer Meinung 
wären, hätte ich echt nicht gedacht.

> Allerdings ist eine "USB Disk" nicht zwangsläufig ein "USB
> Stick".

Natürlich nicht. Deswegen hatte ich ja in meinem Posting direkt eine 
"richtige", aber eben (mangels richtiger Masenspeicherschnittstelle) 
über USB angekoppelte SSD empfohlen (und notfalls eine klassische 
mechanische HD).

> Es gibt USB-Adapter für M.2 SSDs.

Auch das. Eine SATA-SSD via üblicher SATA-USB-Bridge tut's aber auch. 
Nur viel billiger (jedenfalls bezogen auf die am Ende verfügbare 
Speicherkapazität). Diese Variante hat halt vor allem den Vorteil, dass 
man notfalls eben auch problemlos auf eine mechanische HD mit weitaus 
mehr Speicherkapazität pro Cent wechseln kann, wenn es denn nötig werden 
würde.

Das fiele mit der M.2-Lösung schon sehr viel schwerer, oder?

Autor: Fred R. (Firma: www.ramser-elektro.at/shop) (fred_ram)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Schreiber (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Fred R. schrieb:
> Ich vermute mal, das die USB Sticks intern noch über Kondensatoren
> verfügen, welche den BrownOut buffern.

nur wenn der Hersteller da nicht gespart hat.
Selbigs übrigens bei SD-Karten. Auch da kann ein Hersteller 
Kondensatoren einbauen, wenn er denn will...

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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... ;-)

Autor: Sheeva P. (sheevaplug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas S. (doschi_)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
USB -> USV?

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: K. J. (theborg0815) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> 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.

Kann ich bestätigen hab eine 32GB Samsung EVO, im Betrieb seit >1 Jahr 
schreibe alle 5min in die Datenbank, und hab ein komplettes 
Gentoo-System drauf aufgebaut mit Updates für das letzte Jahr, bis jetzt 
keine Probleme, hab auch nix optimiert kein Cache und logs werden auch 
fleißig drauf geschrieben, da könnte man noch etwas dran drehen aber so 
läuft es zufriedenstellend, hatte auch gedacht das die kein Jahr schaft.

Mit Intenso hab ich auch ehr schlechtere Erfahrungen gemacht allerdings 
wahren die meist nur 8GB die verschleißen schneller.

Autor: Sheeva P. (sheevaplug)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas S. schrieb:
> USB -> USV?

Äh, ja.

Autor: Dra (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nimm eine SSD/Usb Stick und lasse die SD ganz weg. Immer wieder haben 
meine rpis das Dateisystem auf der SD gefressen, bis ich ganz auf sie 
verzichtet habe.

Das ist bei mir die stabilste Methode.

Autor: camikusch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
> Diese billigen Flashmedien sind allesamt designed wie Klopapier: am
> Besten nur einmal zu benutzen, alles darüber hinaus stinkt und klebt an
> den Fingern...

zustimm.
hier wird am anfang kurz beschrieben, wie es auf dem flash-markt zugeht:
Youtube-Video "30C3: The Exploration and Exploitation of an SD Memory Card (EN)"

Phil schrieb:
> Größenmässig wäre eine 2,5" SSD überhaupt kein Problem. Bisher läuft es
> alles auf meinem Notebook. Ich hätte einfach gerne etwas dediziertes
> dafür, dass man nicht jedes Mal neu einrichten muss.

dann tu dir doch selbst einen gefallen, und benutze ein extra notebook 
für diese aufgabe. muss ja nichts tolles sein.
das bootet von disk, hält sich an "pc-standards", ist x86-kompatibel, 
hat eine eingebaute USV…
https://www.itsco.de/notebook-dell-latitude-e4200-...

Beitrag #5163593 wurde vom Autor gelöscht.
Autor: Phil (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dra schrieb:
> Nimm eine SSD/Usb Stick und lasse die SD ganz weg

Und wie bootest Du dann?

camikusch schrieb:
> dann tu dir doch selbst einen gefallen, und benutze ein extra notebook
> für diese aufgabe. muss ja nichts tolles sein.
> das bootet von disk, hält sich an "pc-standards", ist x86-kompatibel,
> hat eine eingebaute USV…
> 
https://www.itsco.de/notebook-dell-latitude-e4200-...

Oh, ich wusste nicht, das es so günstig geht. Einziger Haken ist 
fehlendes RS232. Aber mit einem vernünftigen Adapter sollte das ja auch 
per USB stabil laufen.

Autor: Oliver S. (phetty)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Die neueren Raspberries können auch ganz ohne SD aus dem Netz booten:

https://www.raspberrypi.org/documentation/hardware...


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

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
> Das bringt alles nichts, wenn eine 1MB große Datei geschrieben
> werden soll und erst 500kB übertragen sind...

Wir sind nicht blöde. Es geht natürlich um den verlust der bereits 
geschriebenen Daten, insbesondere der Dateien, die abgeschlossen wurden.

Autor: 20TB (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn so 'ne SD Karte übern Jordan geht, hängt dann das gesammte Linux 
oder wird ein "medium error" wie bei den HDDs gemeldet?

Bei einem "medium error" könnte man RAID1 über SD Karte + USB-Stick 
machen (mdadm..)

Autor: camikusch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Phil schrieb:
> camikusch schrieb:
> 
https://www.itsco.de/notebook-dell-latitude-e4200-...
>
> Oh, ich wusste nicht, das es so günstig geht. Einziger Haken ist
> fehlendes RS232. Aber mit einem vernünftigen Adapter sollte das ja auch
> per USB stabil laufen.

ja, aber augen auf: ich hab mir den nochmal angesehen, und es kann sein, 
dass der nur einen 1,8" steckplatz (?) für die HD hat.

trotzdem: KISS-prinzip

Autor: Fred R. (Firma: www.ramser-elektro.at/shop) (fred_ram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

: Bearbeitet durch User
Autor: Dra (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver S. schrieb:
> Die neueren Raspberries können auch ganz ohne SD aus dem Netz booten:


Das können sie neben USB boot auch. Ist dann der nächste Schritt bei 
mir.

Auch wenn dort “experimentell“ steht, so läuft das bei mir unglaublich 
stabil.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wenn so 'ne SD Karte übern Jordan geht, hängt dann das gesammte Linux
> oder wird ein "medium error" wie bei den HDDs gemeldet?

Du bekommst meisten eindeutige fehlermeldungen angezeigt. Allerdings 
kann ein Lesefehler dazu führen, daß du kein Programm mehr starten 
kannst weil benötigte Libraries oder Kernel Module nicht geladen werden 
können.

: Bearbeitet durch User
Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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

Autor: Andi_73 (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Alex G. (dragongamer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bernhard (Gast)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
Hallo,

habe in den letzten Wochen eine stattliche Anzahl uSD-Karten und 
mini-USB-Sticks getestet bezueglich random read/write auf einem 
Raspberry Pi 3. In den naechsten Wochen werde ich dann versuchen, ein 
oder zwei Modelle "kaputtzuschreiben" und durch Stromausfaelle 
kaputtzukriegen, die Ergebnisse werde ich dann ebenfalls hier posten.

Fuer den Test habe ich iozone 3_434 (siehe www.iozone.org) und 
flashbench 0.2 (siehe github.com/hglm/flash-bench) verwendet. Ersteres 
testet quasi auf Sektorebene (Filesystem egal), zweiteres auf 
Filesystemebene. Aufruf wie folgt:

sudo ./flashbench
sudo ./iozone -e -I -a -s 100M -r 4k -i 0 -i 1 -i 2

Alle Angaben in MByte/s, Preise exklusive MwSt. Stand ca. 12/2017. Mein 
Fazit bisher:

Wenn es auf maximale Performance ankommt (ich sage mal, 
Datenbankanwendungen), "Sandisk Extreme 32GB V30" (SDSQXAF-032G-GN6MA) 
verwenden. Eine "Samsung Evo+ 32GB" (MB-MC32DA, "+" und nicht "plus") 
waere durchaus konkurrenzfaehig, alleine, sie ist ein Auslaufmodell und 
praktisch nicht mehr zu bekommen (und der Nachfolger "plus" ist teuer 
und langsam).

Wenn es preiswert mit brauchbarer Performance sein soll, dann "Transcend 
Ultimate 600x 8GB" (TS8GUSDHC10U1) oder "Adata Premier 8GB" 
(AUSDH8GUICL10).

Beantworte auch gerne spezielle Fragen.
iozone Raspi3              |Typ|Typennummer       |EurEx|RRND| WRND |Bmrkg
---------------------------+---+------------------+-----+----+------+--------
Sandisk Extreme 32GB V30   |uSD|SDSQXAF-032G-GN6MA| 16.0| 8.1|  3.8 |
Samsung Evo+ 32GB          |uSD|MB-MC32DA         | 12.5| 8.1|  2.9 |Auslauf
Samsung Evo UHS-I 16GB     |uSD|MB-MP16D          | 10.8| 5.5|  1.2 |
Adata Premier 16GB         |uSD|AUSDH16GUICL10-R  |  6.8| 6.8|  1.1 |
Transcend Ult. U3 V30      |uSD|TS16GUSDU3M       | 14.9| 5.4|  0.9 |
Transcend Ult. 600x 8GB    |uSD|TS8GUSDHC10U1     |  6.5| 6.5|  0.8 |
Verbatim Pro U3 16GB       |uSD|47040             | 11.0| 7.1|  0.8 |
Samsung Evo Plus 32GB      |uSD|MB-MC32GA         | 11.2| 4.5|  0.8 |
Sandisk Ultra 32GB         |uSD|SDSQUAR-032G-GN6MA| 12.1| 5.7|  0.6 |
Samsung Evo UHS-I 32GB     |uSD|MB-MP32DA         | 12.4| 4.2|  0.7 |
xlyne SDHC 8GB             |uSD|7408001           |  5.4| 5.4|  0.4 |
Toshiba Exceria M302-EA 32G|uSD|THN-M302R0320EA   |  9.5| 5.9|  0.2 |
Toshiba Exceria M302-EA 16G|uSD|THN-M302R0160EA   |  6.7| 5.8|  0.2 |
---------------------------+---+------------------+-----+----+------+--------
SanDisk UltraFit V2 32GB   |USB|SDCZ43-032G-GAM46 | 11.5| 5.4|  3.4 |60 Grad!
SanDisk UltraFit V2 16GB   |USB|SDCZ43-016G-GAM46 |  8.0| 4.6|  2.5 |60 Grad!
Intenso Slim Line 3.0 16GB |USB|3532470           |  7.4| 3.8|  0.5 |
Verbatim Nano 16GB         |USB|98709             | 10.0| 4.0|  0.5 |
Toshiba TransMem U364 32GB |USB|THN-U364W0320E4   | 10.5|    |      |Abbruch

flashbench Raspi3 f2fs  |Typ|Typennummer       |EurEx|RSEQ|WSEQ|RRND|WRND
------------------------+---+------------------+-----+----+----+----+----
Sandisk Extreme 32GB V30|uSD|SDSQXAF-032G-GN6MA| 16.0|19.7|19.2| 9.0|19.0
Transcend Ult. 600x 8GB |uSD|TS8GUSDHC10U1     |  6.5|21.5|13.1| 5.7|13.5
Adata Premier 8GB       |uSD|AUSDH8GUICL10     |  5.7|17.8| 7.5| 6.0| 8.7
xlyne SDHC 8GB          |uSD|7408001           |  5.4|14.3|10.9| 4.4| 8.0

flashbench Raspi3 ext4  |Typ|Typennummer       |EurEx|RSEQ|WSEQ|RRND|WRND
------------------------+---+------------------+-----+----+----+----+----
Sandisk Extreme 32GB V30|uSD|SDSQXAF-032G-GN6MA| 16.0|21.9|20.6| 9.3| 6.8
Transcend Ult. 600x 8GB |uSD|TS8GUSDHC10U1     |  6.5|21.5|14.5| 5.9| 1.4
Adata Premier 16GB      |uSD|AUSDH16GUICL10-R  |  6.8|21.6| 9.8| 5.6| 1.5
xlyne 8GB               |uSD|7408001           |  5.4|19.5|11.5| 4.4| 1.4

Zusammenfassend einige Erkenntnisse, die ich aus den Tests gewonnen 
habe:

1) Man muss sich klar darueber sein, dass man die uSD Karten nicht so 
verwendet, wie es vom Hersteller vorgesehen wurde (also z.B. in einem 
Fotoapparat). Die auf den Verpackungen ausgelobten Leistungswerte sind 
daher irrelevant.

2) Fuer die Anwendung im Rpi, speziell wenn man Datenbanken am laufen 
hat, ist die random read/write Leistung ausschlaggebend. Die in z.B. 
Fotoapparaten wichtige sequentielle read/write Leistung (die dann auch 
auf der Packung angegeben ist) ist praktisch irrelevant.

3) Wenn man die Ergebnisse reproduzieren will, muss man sich EXAKT die 
gleiche Type besorgen ueber die Typennummer, z.B. "Samsung Evo+ 32GB" 
Typenbezeichnung MB-MC32DA und die "Samsung Evo Plus 32GB" 
Typenbezeichnung MB-MC32GA.

4) Markennamen und Bezeichnung (z.B. "pro") sind irrelevant. Neuer 
Karten des gleichen Herstellers mit einer vergleichbaren Bezeichnung 
koennen deutlich LANGSAMER im Rpi sein als alte Modell (die neue 
"Samsung Evo Plus 32GB" ist z.B. fast Faktor 4 langsamer bei iozone 
random write als die alte "Samsung Evo+ 32GB"). Auch Karten mit gleicher 
Bezeichnung und unterschiedlicher Groesse koennen sehr unterschiedliche 
Ergebnisse liefern (manchmal sind auch die groesseren langsamer!).

5) Einige min-USB-Sticks sind eine gute Alternative, allerdings bootet 
der Rpi damit ca. 10-15s langsamer aufgrund einer Anfangsverzoegerung. 
Weiters werden die von mir getesteten Sticks mit guter Leistung sehr 
heiss (geschaetzt 60 Grad). Ob das der Haltbarkeit zutraeglich ist 
bezweifle ich.

6) Bei den Bootzeiten unterscheiden sich ALLE oben getesteten uSD Karten 
kaum (maximal so 10%).

7) Das ext4 Filesystem ist weniger gut geeignet und belastet auch die 
Karte staerker (FAT erwaehne ich gleich gar nicht, das ist meiner 
Meinung nach voellig unbrauchbar fuer den Rpi). Ich empfehle f2fs, damit 
habe ich bisher beste Erfahrungen, siehe auch Links:
f2fs.wiki.kernel.org/start
elinux.org/images/0/02/Filesystem_Considerations_for_Embedded_Devices.pd 
f
www.usenix.org/system/files/conference/fast15/fast15-paper-lee.pdf

Autor: Bernhard (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Hallo,

anbei noch eine Liste mit Bootzeiten diverse uSD Karten, die ich 
getestet habe. Die Bootzeit ist in Sekunden angegeben, bis eine von mir 
geschriebene Gtk-App Ihre Oberflaeche auf einem mit startx gestarteten 
X-Server auf dem per HDMI angeschlossenen TFT-Display (Waveshare 7'' 
1024x600) anzeigt auf einem Raspberry Pi 3.
Speichermedium mit f2fs                  |typ|ui
-----------------------------------------+---|---
Sandisk Extreme 32GB (SDSQXAF-032G-GN6MA)|uSD|18s
Adata Premier 16GB (AUSDH16GUICL10-R )   |uSD|17s
Transcend Ult. 600x 8GB (TS8GUSDHC10U1)  |uSD|19s
xlyne SDHC 8GB  (7408001)                |uSD|20s

Speichermedium mit ext4 inkl. fsck       |typ|ui
-----------------------------------------+---|---
Sandisk Extreme 32GB (SDSQXAF-032G-GN6MA)|uSD|25s
Adata Premier 16GB (AUSDH16GUICL10-R )   |uSD|25s
Transcend Ult. 600x 8GB (TS8GUSDHC10U1)  |uSD|26s

P.S.: Sorry fuer das crosspost, hatte den Artikel zunaechst 
unabsichtlich als "Neuer Beitrag" eingestellt.

Autor: Alex G. (dragongamer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Cmdr.Data (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
8)

Aufpassen!
Die schreib/lese Datenraten der (µ)SD Karten können sich über die Zeit 
durchaus ändern (zum schlechteren)!

Gesehen z.B. bei einer Samsung 128GB EVO+ nach 15 Monaten mit exFAT und 
weniger als 1 TBW (von ~20MByte/s auf teilweise unter 10MByte/s 
lin.Write).

Dateigröße meist war 5 .. 20 MByte.

Autor: c-hater (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Cmdr.Data schrieb:

> Aufpassen!
> Die schreib/lese Datenraten der (µ)SD Karten können sich über die Zeit
> durchaus ändern (zum schlechteren)!


Können?! Werden!!

Mir ist noch absolut kein Flash-Speicher über den Weg gelaufen, der 
jemals schneller geworden wäre als er im Neuzustand war...

Schlimmer noch: Heutzutage kann man schon fast glücklich sein, wenn 
diese Scheisse wenigstens zweimal "vollständig" (also: geschriebene 
Datenmenge >2x Kapazität) beschrieben werden kann. Jedenfalls soweit es 
SD-Cards und USB-Sticks betrifft und das bei von der Vorgabe 
abweichender Partitionierung/Formatierung. Aber selbst, wenn man die 
einhält, ist es heute kaum noch möglich, >4x Kapzität zu schreiben ohne 
dass der Rotz abkackt. Die besseren Teile lassen einen dann wenigstens 
noch lesend zugreifen...

Flash-Medien sind Beschiss in globalem Maßstab. So haltbar wie 
Klopapier...

Beitrag #5259340 wurde von einem Moderator gelöscht.
Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ansonsten mal nach "high endurance" Karten schauen.

Autor: Alex G. (dragongamer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: c-hater (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Alex G. schrieb:

> Nach 4 mal Vollschreiben, Probleme, ist dann doch etwas übertrieben.

Stimmt und stimmt doch nicht.

Wenn man die Dinger mit dem Update vieler kleinerer Dateien quält, sind 
4x sogar noch sehr optimistisch...

Blöderweise ist aber gerade das das Szenario, wenn man ein OS davon 
laufen läßt und nicht nur (relativ große und immer wieder neue) 
Video-Captures darauf speichert.

Aber was soll ich mir hier den Mund fusselig reden. Jeder kann gerne 
seine eigenen Erfahrungen sammeln, wenn er mir nicht glaubt. 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?

Ü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.

Mal angenommen, man hätte ein Gehirn im Kopf und könnte damit 
tatsächlich denken: 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?

Tja, wer selbstständig denken kann, ist wohl ganz klar erheblich im 
Vorteil...

Autor: Torben (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Alex G. (dragongamer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: Bernhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex G. schrieb:

> Interessante Daten!
> War sicher einiges an Mühe!

Ja, war aber fuer mich notwendig, weil die Unterschiede durchaus 
eklatant sind und man will ja nicht den schnellen Raspi3 ausbremsen, die 
uSD ist sowieso der Schwachpunkt der ganzen Hardware.

Hat auch ein bisschen was gekostet, ich habe mir von jeder Sorte 2 
Stueck besorgt, man kann ja nie wissen (hatten aber immer alle durchwegs 
gleiche Daten). Deshalb poste ich das ja hier, damit es einen 
Zusatznutzen auch fuer andere hat.

> Ein paar Fragen aber:
> 1. Sind schwankungen bei den Tests da, oder kamen bei Wiederholungen,
> stets sehr ähnliche Werte raus?

Stets sehr aehnlich, Schwankungen maximal so 0.1 MByte/s bei iozone, bei 
flashbench vielleicht mal 0.5 MByte/s.

> 2. Wofür steht EurEx?

Euro exklusive Mehrwersteuer. Steht oben irgendwo (viel Text, ich 
weiss).

Besonders die Sandisk Extreme ist schon ziemlich teuer. Aber die iozone 
Daten rechtfertigen den Preis, die Karte ist schon ein ganz andere 
Kategorie als die anderen (lustigerweise auch als die Sandisk Ultra, die 
ist nur Mittelklasse).

Die sequentiellen Raten beim Schreiben und Lesen ueber einen USB 3.0 uSD 
Reader/Writer hat mit dd bei einem Raspbian-Image mit der Sandisk 
Extreme mit 68 Megabyte/s Schreibrate und 92 Megabyte/s Leserate 
angezeigt.

> 3. Sind das alles Megabytes, oder Megabits?

Megabyte pro Sekunde, steht auch oben irgendwo.

> 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 :)

Natuerlich muss man das automatisieren, ich denke aber, mit dem 
richtigen (selbstgeschriebenen) Testprogramm werden ich die Dinger schon 
kaputtkriegen. Die Frage ist lediglich, nach wievielen GB oder gar TB. 
Das kann also schon ein wenig dauern, bis ich hier was posten kann ;-)

Allerdings werde ich nicht ALLE kaputtschreiben (zuviel Arbeit), sondern 
nur die, die ich selbst fuer die Zukunft ins Auge gefasst habe, also die 
Sandisk Extreme, die Transcend Ultimate 600, die Adata und vielleicht 
die Billigsdorfer xlyne (die will ich zwar nicht einsetzen, aber ist 
evtl. interessant zu wissen, wie sich so ein Billigschrott haelt).

> Sehr interessant dass die Bootzeit bei f2fs schon deutlich kürzer ist.

Das ist hauptsaechlich, weil ein fsck nicht noetig ist bzw. quasi 
automatisch ablaeuft beim mounten des f2fs und sehr schnell ist (siehe 
"Checkpointing" usw. in den verlinkten f2fs Dokus). Beim ext4 habe ich 
das fsck aber jedesmal erzwungen (4-5 Sekunden zusaetzlich), in der 
richtigen Anwendungen waere das aber auch zwingend notwendig (falls es 
Stromausfall geben kann).

> Hat das Filesystem irgendwelche Nachteile?

Mir sind keine aufgefallen und ich habe auch nichts belastbares im 
Internet gefunden, was gegen das f2fs spricht. Das ist ja gerade fuer 
Flash-Speicher entworfen worden und hat auch schon ein paar Jahre auf 
dem Buckel. Falls mir in meiner Anwendung in Zukunft was auffallen 
sollte, werde ich das hier posten wenn Du willst.

> 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.

Naja, Ich mache alle Tests mit f2fs (weil ich das dann spaeter 
einzusetzen gedenke). Das ist ein log structured fs, daher nuetzt der 
Test nichts, weil die 10kB Datei sowieso nicht wirklich ueberschrieben 
werden (bzw. erst, wenn die ganze uSD voll ist).

> Das ist ein viel realistischeres Anwendungsscenario und man kann sehen
> ob die Karten (oder wahrscheinlicher die STicks) ein funktionierendes
> Write-Balancing wie SSDs haben.

Grundsaetzlich richtig, zumindest waere es das fuer ext4. Das f2fs hat 
aber eben aufgrund der log-strukturierung quasi sowieso schon mal ein 
"intrinsic" wear leveling.

Autor: Bernhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Cmdr.Data schrieb:

> Aufpassen!
> Die schreib/lese Datenraten der (µ)SD Karten können sich über die Zeit
> durchaus ändern (zum schlechteren)!

Das kann es geben, hauptsaechlich wegen des wear leveling.

> Gesehen z.B. bei einer Samsung 128GB EVO+ nach 15 Monaten mit exFAT und
> weniger als 1 TBW (von ~20MByte/s auf teilweise unter 10MByte/s
> lin.Write).
> Dateigröße meist war 5 .. 20 MByte.

Obwohl viele Hersteller in der Tat ihre SD-Karten (den Controller da 
drin) auf FAT "optimieren", ist FAT eine ganz schlechte Wahl fuer eine 
SD-Karte.

Autor: Bernhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:

> Können?! Werden!!
> Mir ist noch absolut kein Flash-Speicher über den Weg gelaufen, der
> jemals schneller geworden wäre als er im Neuzustand war...

Das darf man auch nicht wirklich erwarten, oder?

> Schlimmer noch: Heutzutage kann man schon fast glücklich sein, wenn
> diese Scheisse wenigstens zweimal "vollständig" (also: geschriebene
> Datenmenge >2x Kapazität) beschrieben werden kann. Jedenfalls soweit es
> SD-Cards und USB-Sticks betrifft und das bei von der Vorgabe
> abweichender Partitionierung/Formatierung. Aber selbst, wenn man die
> einhält, ist es heute kaum noch möglich, >4x Kapzität zu schreiben ohne
> dass der Rotz abkackt. Die besseren Teile lassen einen dann wenigstens
> noch lesend zugreifen...

Mindestens 30x erwarte ich mir schon. Bin schon gespannt, wie meine 
"Kaputtschreibtests" verlaufen werden. Gerne poste ich das Ergebnis 
hier. Angesichts Deiner schlechten Erfahrungen vielleicht doch noch 
frueher als ich dachte ;-)

> Flash-Medien sind Beschiss in globalem Maßstab. So haltbar wie
> Klopapier...

Ein in doppelter Hinsicht schoener Vergleich ;-)

Vielleicht hilft es ja, immer nur 1/2 oder 2/3 zu beschreiben bzw. zu 
Partitionieren und den Rest dem Controller als Ersatz fuer kaputte 
Sektoren zu ueberlassen? Zweilagiges Klopapier haelt ja auch viel besser 
als einlagiges ;-)

Autor: Bernhard (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Alex G. schrieb:

> Probleme haben sie halt im Falle des Raspberry's da dessen Fileformat,
> die Bemühungen der Hersteller zunichte macht.

Exakt.

> Dieses F2FS Format - welches grad für Flash Friendly File System steht,
> klingt darum besonders interessant.

So ist es.

Wenn man sich die Funktionsweise eines ext-Filesystems ansieht (FAT ist 
bezueglich der FLASH-Belastung eher noch schlechter, aber die Controller 
in den SD-Karten sind i.a. darauf optimiert) und im Vergleich dazu das 
f2fs (siehe 
https://www.usenix.org/system/files/conference/fas...) 
dann wird auch schnell klar, wieso.

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex G. schrieb:

> Erstmal Geschwindigkeit. Eine MicroSD nutzt niemand in einem PC als
> Systemplatte.

Aber man nutzt sie als System-"Platte" z.B. in RasPis. Und genau dort 
zeigt sich z.B. das ganze Elend. Wie sich in zahllosen Beiträgen in 
einschlägigen Foren nachlesen läßt...

Ich persönlich habe allerdings meine diesbezüglichen Erfahrungen 
überwiegend tatsächlich mit konventioneller x86-Technik unter Linux 
gesammelt. Mini-ITX-Board als WLAN-Accounting-Server (nix ungewöhliches: 
lighthttpd, hostapd, postgresql und ein paar Scripte) .

Und natürlich habe ich alle einschlägigen Tricks verwendet, um den 
Flash-Nachteil möglichst gering zu halten (mountoptions noatime, 
relatime). Hat aber nur sehr wenig gebracht.

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

Das sagst du, aber frag' mal einen geistig Gesunden...

> Btw. langlebiegr Flash dürfte wohl nicht so teuer sein.

Doch, ist er. Das sind nämlich einfach die SSDs. Und die sind eben 
einfach mal sehr viel teuerer als dieser Billig-Gammel.

Autor: Bernhard (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
c-hater schrieb:

> Wenn man die Dinger mit dem Update vieler kleinerer Dateien quält, sind
> 4x sogar noch sehr optimistisch...

Mit ext oder fat ist da ganz sicher was dran, aber warum gleich so 
aufgeregt?

Das f2fs funktioniert voellig anders, deshalb ist es auch deutlich 
schneller beim Schreiben kleiner Daten (weil die im Prinzip sequentiell 
geschrieben werden) und auch die Belastung einzelner Sektoren ist im 
Prinzip ausgeglichen auf die ganze Karte.

Falls jemand daran denkt, SQLite auf einer SD-Karte auf dem Raspi laufen 
zu lassen: Die aktuelle Version 3.21 hat offenbar eine spezielle 
Schreiboptimierung fuer f2fs parat (soweit ich weiss, nur im SQLite WAL 
Modus, aber den sollte man sowieso verwenden).

Siehe auch hier: 
https://www.phoronix.com/scan.php?page=news_item&p...

Die 3.21 muesste man sich dann selber compilieren auf dem Raspi, das ist 
aber nicht weiter kompliziert.

> Blöderweise ist aber gerade das das Szenario, wenn man ein OS davon
> laufen läßt und nicht nur (relativ große und immer wieder neue)
> Video-Captures darauf speichert.

Ganz recht.

> Übrigens, was SSDs betrifft:die sind um ein Vielfaches besser als dieser
> Billichscheiss von USB-Sticks oder SD-Cards.

Auch das ist korrekt.

Autor: Bernhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex G. schrieb:

> 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.

Korrekt, habe ich hier eines rumliegen. Leider habe ich davon dzt. nur 
einen alten Flashbench Messwert mit ext4. Hier nochmal die Messwerte im 
Vergleich mit der Sandisk Extreme (die anderen sind keine Gegner fuer 
das CM3):
flashbench Raspi3 ext4  | Typennummer        |RSEQ|WSEQ|RRND|WRND
------------------------+--------------------+----+----+----+----
Sandisk Extreme 32GB V30| SDSQXAF-032G-GN6MA |21.9|20.6| 9.3| 6.8
CM3 eMMC 4GB            |                    |22.0|17.0| 9.5| 6.5

Wenn es gewuenscht ist, kann ich mit dem CM3 noch flashbench Messungen 
mit f2fs sowie iozone Messungen anstellen.

> 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.

Ueber die Lebensdauer kann und werde ich nichts sagen, das Teil ist mir 
doch zu schade zum kaputtschreiben ;-)
Allerdings sollte eMMC eine deutlich laengere Lebensdauer haben als 
SD-Karten.

Das CM3 hat aber zwei entscheidende Nachteile:
1) Nur 4GB
2) Man braucht eine selbstentwickeltes "Motherboard" mit den ganzen 
Steckern drauf (das IO-Board ist nur zum Entwickeln/Testen brauchbar)

Autor: Bernhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Schwer zu sagen. Jedenfalls ist Samsung einer von nur vier (der groesste 
sogar) Herstellern von FLASH-Speichern weltweit. Und auch die Samsung 
SD-Karten sind so schlecht nicht. Von daher besteht Hoffnung, dass da 
was brauchbares drin steckt.

Details am Rande:

Interessant ist, dass Sandisk ueberhaupt kein FLASH selbst herstellt 
(jedenfalls seit vielen Jahren nicht mehr), sondern dass die Sandisk uSD 
von Toshiba kommen.

Noch interessanter ist, dass die Toshiba uSD und auch der USB-Stick, die 
ich getestet haben, die schlechtesten ueberhaupt waren (siehe meine 
Testliste oben). Der USB-Stick war selbst nach einer Stunde Test zu 
keinem Ende gekommen bei iozone (dauert normalerweise ein paar Minuten). 
Ich schaetze eine Schreibrate von < 0.1MByte/s, die Sandisk Extreme (die 
ja von Toshiba kommt) ist also wohl einen FAKTOR 50 oder mehr schneller.

> Oder anders gefragt: Lässt sich tatsächlich ein Teil der zunehmenden
> "Langsamkeit" der Smartphones über das Altern des Flashs erklären?

Eher mit zuwenig RAM und zuwenig freiem Speicher im FLASH. Im Laufe der 
Zeit muellt man ja RAM und FLASH tendenziell immer mehr zu.

Man kennt ja den Spruch: Der Fuellstand einer BELIEBIG grossen 
Festplatte erreicht nach 6 Monaten immer 90% ;-)

Autor: Dieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: B. R. (bero)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

: Bearbeitet durch User
Autor: slowSD (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier mal die iozone Messwerte einer Samsung Evo+ 32GB" (nicht "plus"):
   kB       reclen    write  rewrite    read    reread    rnd-rd   rnd-wr
1: 102400       4     1281     1751     5695     5695     5604     1800 
2: 102400       4     1448     1345     5642     5643     5551      827 

Bereich 1: selten beschrieben
Bereich 2: oft beschrieben

fs: ext4

Autor: soul e. (souleye)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex G. schrieb:

> 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.

Eine Flashzelle gilt als "kaputt" wenn sie die spezifizierte data 
retention time nicht mehr einhält. Daher musst Du nach jedem 
Schreibzyklus 12 oder 24 Monate warten und dann prüfen ob es noch 
Lesefehler gibt.

Immer auf die gleiche Stelle schreiben und gucken wann die ersten 
I/O-Error auftauchen kann man natürlich machen. Das liefert aber keine 
Aussage über die Lebendauer in der Praxis, denn da sollen die 
geschriebenen Daten üblicherweise auch eine Weile erhalten bleiben. 
Zwischen "Daten bleiben nur noch 11 Monate erhalten" und "Zelle ist so 
kaputt dass direkt I/O-Error kommt" können durchaus mehrere 
Zehnerpotenzen an Schreibvorgängen liegen.

Autor: B. R. (bero)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernhard R. schrieb:
> 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.

Das nenne ich eine messerscharfe Analyse. Du hast bestimmt Abitur.

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: B. R. (bero)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: B. R. (bero)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: B. R. (bero)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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 ;-) .

Autor: S. R. (svenska)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: B. R. (bero)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: soul e. (souleye)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Bernhard R. schrieb:

> 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).

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.

Die meisten SD-Karten sind aber für lineares Vollschreiben gefolgt von 
Komplettlöschung ausgelegt (Digitalkamera). Daher sind die Algorithmen 
oft deutlich schlechter als bei SSDs bzw. CF-Karten.

Autor: B. R. (bero)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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.

Autor: soul e. (souleye)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Bernhard R. schrieb:

> 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

Der Controller interessiert sich nicht für Filesysteme. 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.

Autor: B. R. (bero)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: soul e. (souleye)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Bernhard R. schrieb:

> Das kann er aber nur, wenn er freie/unbenutzte Sektoren zur Verfuegung
> hat.

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. Dafür hält der Controller aber genügend 
interne Reserve vor.

Zum Tauschen sind drei Schreibvorgänge notwendig: A-->temp, B-->A, 
temp-->B. Mit Overprovisioning oder bei Kenntnis des unbenutzen 
Bereiches (über TRIM) kann dies auf einen einzelnen Schreibvorgang 
(A-->A', A als frei markieren) reduziert werden. Die Anpassung der 
Zuordnung NAND-Blockadresse zur (für den Host sichtbaren) Logical Block 
Address (LBA) kommt natürlich in beiden Fällen noch dazu.


Richtig ist, dass die wear levelling-Algorithmen durchaus auf 
Dateisystemtypen und use cases (linerares Vollschreiben bei der Kamera 
etc) optimiert sind. Trotzdem funktionieren sie auch beim 
"Dateisystemtyp" Raw, d.h. vollkommen willkürlichem Zugriff auf den 
kompletten Datenbereich noch.

: Bearbeitet durch User
Autor: 900ss D. (900ss)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: soul e. (souleye)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
900ss D. schrieb:

> (...) Beim einem Schreibzugriff (und nur dann)
> von Block X sucht er sich einen neuen physikalischen Block, wenn das
> wear-leveling es vorgibt.

Exakt. Und wenn dieser mit Userdaten belegt ist, packt er die woanders 
hin. Das ist das, was ich als "umkopieren" bezeichnet habe. So werden 
auch statische Userdaten gelegentlich neu geschrieben und so refreshed.

Autor: 900ss D. (900ss)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Mikro 7. (mikro77)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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? ;-)

Autor: 900ss D. (900ss)
Datum:

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

:)

Autor: 900ss D. (900ss)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Phil (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mikro 7. schrieb:
> Das wäre allerdings imho die einzige Möglichkeit (und technisch einfach
> zu realisieren) um den Ausfall der Zellen zu verhindern.

Warum wäre das umkopieren einfach und einzig? Ich finde diesen Gedanken 
beim nächsten Schreiben einfach den nächsten zu nehmen irgendwie 
sinnvoller. Ein einfaches umkopieren erzeugt doch nur einen völlig 
unsinnigen Schreibzugriff.

Autor: Christopher J. (christopher_j23)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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...
http://wiki.laptop.org/go/How_to_Damage_a_FLASH_St...

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: soul e. (souleye)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Phil schrieb:

> Warum wäre das umkopieren einfach und einzig? Ich finde diesen Gedanken
> beim nächsten Schreiben einfach den nächsten zu nehmen irgendwie
> sinnvoller. Ein einfaches umkopieren erzeugt doch nur einen völlig
> unsinnigen Schreibzugriff.

Und was tust Du wenn kein nächster mehr frei ist? In diesem Fall bleibt 
nichts anderes übrig als einen wenig genutzten belegten zu nehmen und 
dessen Originalinhalt auf einer abgerittenen Speicherzelle in Rente zu 
schicken.

Natürlich werden beim dynamic wear levelling keine belegten Blöcke 
freigeräumt solange noch frische freie vorhanden sind. Ausgangsbasis war 
aber eine zu 100% belegte Karte, d.h. bekannt freie Blöcke gibt es nur 
im Reservebereich.

: Bearbeitet durch User
Autor: Mikro 7. (mikro77)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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...

: Bearbeitet durch Moderator
Autor: Mikro 7. (mikro77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

: Bearbeitet durch User
Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: 900ss D. (900ss)
Datum:

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

Es ist wirklich ein spannendes Thema finde ich.

: Bearbeitet durch User
Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da hätten wir aber noch das Problem, welches sich schon vor einigen 
Jahrzehnten bei entsprechenden Methoden im EEprom ergeben hat:

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?

Autor: B. R. (bero)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: B. R. (bero)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: B. R. (bero)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alex G. (dragongamer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mikro 7. (mikro77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: usuru (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Warum auch? Damit kannst du höchstens die logische Struktur der Daten 
beschädigen, aber nicht die Hardware.

Was die Hardware beschädigt, ist das ganz normale Schreiben und Löschen 
von Flash-Pages. Ganz genau so, wie Klopapier rein durch vollkommen 
zweckgerechte Benutzung unbrauchbar gemacht wird.

Es geht halt bloß nicht ganz so schnell wie bei Klopapier und durch 
nicht dokumentierte "Wende-" bzw. "Blattaustausch-" Techniken ist es 
sehr schwer nachvollziehbar, zumal die zwingend nötigen Aufzeichnungen 
für diese Techniken auch wieder auf dem gleichen Klopapier-Speicher 
liegen...

Autor: S. R. (svenska)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Alex G. (dragongamer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: c-hater (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
S. R. schrieb:

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

Ja. Nur werden die Seiten mit der Firmware eben niemals geschrieben, 
können also auch niemals durch wegen Energiemangel "verreckender" 
Schreibvorgänge korrumpiert werden.

Das Problem sind die Seiten, in denen die internen 
Verwaltungsinformationen der Firmware stehen, nicht die, in denen die 
Firmware selbst steht.

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: c-hater (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Thomas O. schrieb:

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

LOL

Sach' mal, in dieser (unserer) Welt bist du noch nicht sehr lange, oder?

Autor: soul e. (souleye)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Thomas O. schrieb:

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

Das allerdings nur unter einer Geheimhaltungsvereinbarung.

Die Hersteller passen auch ihre Algorithmen an Deine Anforderungen bzw 
Deinen use case an, genau wie früher die Festplatten-Lieferanten. Du 
musst halt für ausreichend Umsatz sorgen, das ist die Voraussetzung.

Autor: Karl (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
B. R. schrieb:
> Die Algorithmen sollten wenn moeglich nahe am Nutzungsmuster eines Rpi
> liegen

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

Zum Beispiel wird ja für einfaches Datenloggen gern eine Datenbank wie 
mySQL verwendet. Oder gar Round-Robin.

Nun halte ich Round-Robin gerade auf einer SD-Karte für kontraproduktiv, 
weil ja immer wieder in den selben Speicherbereich geschrieben wird.

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?

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.

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

Oder ist das übertrieben?

Autor: Karl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Witzig finde ich, hier wurde mehrmals von Sandisk abgeraten, und die 
Samsung EVO bevorzugt.

Ich hab bereits 2 tote Samsung EVO (16GB und 32GB) rumliegen, eine 
nurmehr readonly, die andere brachte ständig Fehler im Raspi bis zum 
Einfrieren beim Update, also offenbar auch Schreibfehler.

Seitdem ich Sandisk Ultra 16GB und 32GB in den Raspies habe ist Ruhe.

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

: Bearbeitet durch Moderator
Autor: SDMI (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
> 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,

Dann mal bitte: Butter => Fische!

Ein
mmc extcsd read /dev/mmcblk0
oder
smartctl -d test /dev/mmcblk0
waren bisher immer erfolglos..

Danke!

Autor: Mikro 7. (mikro77)
Datum:

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

Autor: Thomas O. (kosmos)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Mikro 7. (mikro77)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: soul e. (souleye)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas O. schrieb:

> (...) Ich denke nicht das die dann wirklich die Blöcke mit
> bereits verwendeten tauschen. Da würden die Schreibraten ja extremst
> einbrechen.

Dann denk Du mal. Die Hersteller werden deswegen das dynamic wear 
levelling nicht abschaffen.

Einen Tipp, wie man interne Schreibaktivitäten ausserhalb der 
Host-Zugriffe nachweisen kann, hat Lothar Dir ja gegeben.

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: soul e. (souleye)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Auch Samsung und Sandisk haben seit dem white paper von 2003 ihre 
Algorithmen ein wenig weiterentwickelt. Da arbeiten nicht nur 
Arduino-Bastler.

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: SDMI (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:

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

Hm, hier (HP notebool) ist es eine PCI-to-X bridge:
lspci
..
46:06.1 System peripheral: Ricoh Co Ltd R5C843 MMC Host Controller 

Autor: Thomas O. (kosmos)
Datum:

Bewertung
1 lesenswert
nicht lesenswert

Autor: 900ss D. (900ss)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

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

Was hat das jetzt mit einem Raspberry Pi zu tun?

Autor: B. R. (bero)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: B. R. (bero)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: B. R. (bero)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: B. R. (bero)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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):
flashbench Raspi3 f2fs  |Typ|Typennummer       |EurEx|RSEQ|WSEQ|RRND|WRND
------------------------+---+------------------+-----+----+----+----+----
Sandisk Extreme 32GB V30|uSD|SDSQXAF-032G-GN6MA| 16.0|19.7|19.2| 9.0|19.0
Transcend Ult. 600x 8GB |uSD|TS8GUSDHC10U1     |  6.5|21.5|13.1| 5.7|13.5
Adata Premier 8GB       |uSD|AUSDH8GUICL10     |  6.8|17.8| 7.5| 6.0| 8.7
xlyne SDHC 8GB          |uSD|7408001           |  5.4|14.3|10.9| 4.4| 8.0

flashbench Raspi3 ext4  |Typ|Typennummer       |EurEx|RSEQ|WSEQ|RRND|WRND
------------------------+---+------------------+-----+----+----+----+----
Sandisk Extreme 32GB V30|uSD|SDSQXAF-032G-GN6MA| 16.0|21.9|20.6| 9.3| 6.8
Transcend Ult. 600x 8GB |uSD|TS8GUSDHC10U1     |  6.5|21.5|14.5| 5.9| 1.4
Adata Premier 16GB      |uSD|AUSDH16GUICL10-R  |  6.8|21.6| 9.8| 5.6| 1.5
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/fas....
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.

Autor: B. R. (bero)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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?

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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. Maker Information             : pSLC
 2. WearSel Type                  : Embedded
 3. Endurance Life Ratio          : 0.00%
 4. Good Block Ratio              : 98.60%
 5. F/W ECC BIT Setting           : 42
 6. Total Refresh Count           : 0
 7. Total Power Up Count          : 84633
 8. Abnormal Power On Count       : 0
 9. Erase Count :       Average   : 37584
                       Maximum    : 37752
                    Total Number  : 37810363
                 Erase Endurance  : 20000
10. Maximum Block Replace Number  : 48
11. Scan Bad Block                : 30
      DIE  : Early Bad  : Later Bad
      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.

: Bearbeitet durch Moderator
Autor: Karl (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
S. R. schrieb:
> SD-Karten sind in meiner
> Wahrnehmung schlicht unzuverlässig und ext4 kann da möglicherweise noch
> mehr retten als f2fs.

Das ist aber jetzt Jammern auf hohem Niveau. Du hast anscheinend noch 
nie 1.44er Disketten in nem Amiga 500 gehabt. DAS ist unzuverlässig.

Btw: Gibt es eine Möglichkeit µSD-Karten die auf readonly gesetzt sind 
wieder beschreibbar zu machen, so dass man sie formatieren und testen 
kann? Google liefert dazu nur: Stell den Schreibschutzschalter um. Ja 
klar, bei einer µSD...

Autor: soul e. (souleye)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl schrieb:

> Das ist aber jetzt Jammern auf hohem Niveau. Du hast anscheinend noch
> nie 1.44er Disketten in nem Amiga 500 gehabt. DAS ist unzuverlässig.

Naja, sowohl meine (knapp 400) 5,25"-Disketten von 1985+ als auch die 
3,5" von 1990+ sind heute noch einwandfrei lesbar. Das hat noch kein 
USB-Stick und keine SD-Karte geschafft.

Schrott waren nur "späte" 3,5"-Disketten ab Ende der '90er.


> Btw: Gibt es eine Möglichkeit µSD-Karten die auf readonly gesetzt sind
> wieder beschreibbar zu machen, so dass man sie formatieren und testen
> kann?

Ja, mit dem Herstellertool den Controller neu initialisieren. Der geht 
dann erstmal davon aus, dass alle Flashzellen gut sind (deine 4 GB-Karte 
hat dann auf einmal 10 GB) und streicht die schlechten wieder raus. Bei 
der Gelegenheit wird auch die kundenerlebbare Nenn-Speicherkapazität 
(eben diese 4 GB) gesetzt. Hier besteht die Gelegenheit zum Betrug, man 
könnte auch 8 GB eintragen. Oder 16 GB.

Die Tools unterliegen genauso einem NDA wie die Algorithmen, aber 
vielleicht ist ja irgendwo mal was rausdiffundiert.

: Bearbeitet durch User
Autor: 900ss D. (900ss)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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 :)

Autor: MMC (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:

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

Antworten denn die XMore Karten auch auf:
mmc extcsd read /dev/mmcblk0 ?

Oder ist das den (neueren) eMMC Chips vorbehalten?

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
1 lesenswert
nicht lesenswert
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/Datenblae...
Auf Nachfragen und bei speziellen Problemen gibt es aber auch andere 
Wearlevel-Algorithmen. Und dann kommt z.B. ein E ans Ende...

: Bearbeitet durch Moderator
Autor: People for the Ethical Treatment of SD Cards (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lothar M. schrieb:
>  9. Erase Count :       Average   : 37584
>                        Maximum    : 37752
>                     Total Number  : 37810363
>                  Erase Endurance  : 20000

Oh-je!
Die arme Karte!
Gönn' ihr doch mal eine Pause!


So eine Woche bei 0,0V und 60-85°C währen interessant.

Autor: Lothar M. (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...  ;-)

: Bearbeitet durch Moderator
Autor: B. R. (bero)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).
 Nr | uSD                         | fs | TB | MB/s 
----+-----------------------------+----+----+-----
  1 | xlyne 8GB 7408001           |ext4| 1.3|  3.4 
  2 | xlyne 8GB 7408001           |f2fs| 1.3|  8.0 
  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.

Autor: Alex G. (dragongamer)
Datum:

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

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

Autor: B. R. (bero)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: B. R. (bero)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: B. R. (bero)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
900ss D. schrieb:
> 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.

Der Sinn ist doch, die SCHREIBLAST moeglichst gleichmaessig auf die 
vorhandenen Bloecke zu verteilen. Und beliebig viel Rechneleistung hat 
so ein winziger uSD Controller auch nicht. Von daher waere eine 
Schreibzaehler in den Bloecken eine billige und gute Loesung.

Ich habe mit sowas theoretische UND praktische Erfahrungen (ein von mir 
selbst vor 10-15 Jahren entwickeltes FS verwendet wear-leveling mit 
Schreibzaehlern auf mehreren tausend Geraeten und immer wenn ich da 
nachschaue, sehe ich, dass die Schreiblastverteilung fast optimal ist).

Die Diskussion, ob auf einer uSD wear-leveling Algorithmen vorhanden 
sind und wenn ja, von welcher Art die sind, ist sinnlos, weil die 
Hersteller keine belastbaren Informationen rausruecken und diese Infos 
bei den Consumer-uSD sowieso rasch veralten, siehe oben das 
Performance-Fiasko bei der "Samsung Evo+ 32GB" (MB-MC32DA) und dem 
Nachfolger "Samsung Evo Plus 32GB" (MB-MC32GA). Ausserdem ist der 
Algorithmus von aussen nicht direkt beeinflussbar.

> 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.

Der interne Algorithmus ist mir egal (Gruende siehe oben).

Durch die Log-Struktur des f2fs ergibt sich in der Praxis ein 
sequentielles schreiben, also ein fast optimales "intrinsisches" 
wear-leveling. Es ist aeusserst unwahrscheinlich, dass das nachteilig 
fuer das zusaetzliche waer-leveling eines uSD Controllers ist (wie auch 
immer das aussieht). Genau darauf (sequentielles schreiben) ist der 
Controller vermutlich sogar optimiert (wenn er ueberhaupt wear-leveling 
macht).

Auf das schreiben von vielen kleinen Datenbloecken wie das bei Rpi+ext4 
auftritt, ist so ein uSD Controller eben gerade nicht optimiert, das ist 
ja genau das Problem an der ganzen Sache.

FAT hat insbesondere beim Einsatz auf einem RPI3 so viele Nachteile, das 
das ueberhaupt nicht in Frage kommt.

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

Natuerlich nicht. Die Optimierung zielt auf, salopp formuliert, FAT + 
Anwendung in Kameras ab. Da die Anwendung auf einem Rpi eine wesentlich 
andere ist, ist FAT mit seinen ganzen anderen Nachteilen da drauf eine 
ganz schlechte Idee.

> 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.

Genau das mache ich doch (exkl. FAT). Siehe auch viel weiter oben z.B. 
meine Performance-Messungen an etlichen verschiedenen Kartentypen.

Langsam werde ich der nicht sehr produktiven Diskussion muede.

Meine theoretische Ueberlegungen (und die von ein paar anderen Leuten, 
weiter oben habe ich Links zum f2fs angegeben) UND die praktischen 
Messergebnisse zeigen mir, dass das f2fs etliche Vorteile gegenueber 
ext4 auf Consumer-uSD auf einem Rpi3 hat und im wesentlichen keine 
nennenswerten Nachteile gegenueber anderen FS.

Daher habe ich beschlossen, f2fs zukuenftig in meinen Projekten mit je 
nach Anwendungsfall 2-3 verschiedenen ausgewaehlten uSD Kartentypen 
einzusetzen, die ich jetzt noch bezueglich Haltberkeit teste.

Die Testergebnisse und Schlussfolgerungen teile ich gerne hier. Wer 
damit nichts anfangen kann oder will, mag sie ignorieren.

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
B. R. schrieb:
>> 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.
>
> Genau das mache ich doch (exkl. FAT).

:-D

Autor: B. R. (bero)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
900ss D. schrieb:
>> Genau das mache ich doch (exkl. FAT).
> :-D

ext4 und f2fs habe ich wohl getestet.

Geht's Dir um FAT? Dann musst Du leider selber testen, weil dieses 
"Filesystem" fasse ich nicht mit der Kneifzange an.

Fuer den Schrott hat Micros~1 ;-) frueher mal sogar Lizenzgebuehren fuer 
jede SD Karte verlangt.

Autor: 900ss D. (900ss)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
B. R. schrieb:
> Geht's Dir um FAT?

Nur wenn du den Test auch machst, hast du den ehrlichen Vergleich, ob 
eine SD-Karte mit FAT eher den Geist aufgibt als mit f2fs/ext4.

Mir ist es aber egal. Du machst den Test für dich.

Und solange du nicht erklärst, wie du die Blöcke physikalisch 
adressieren kannst, wenn die Karte ein wear-leveling hat, verstehe ich 
dich eh nicht.  Und das wear-leveling kannst du nicht ausschließen.

: Bearbeitet durch User
Autor: InFo (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
B. R. schrieb:
> Fuer den Schrott hat Micros~1 ;-) frueher mal sogar Lizenzgebuehren fuer
> jede SD Karte verlangt.

SD-Karten (und deren Nachfolger SDHC und SDXC) sind laut Standard mit 
FAT16 (FAT32, exFAT) formatiert. Diese Formatierung kommt vom Hersteller 
und ist nicht identisch mit der Formatierung, die du da selbst drauf 
machst. Damit ist dein Test grundsätzlich schonmal außerhalb der 
Spezifikation.

In so einer SD-Karte kann ein 8051 drin sein, oder ein ARM Cortex-M. 
Insbesondere letztere sind durchaus in der Lage, ziemlich komplexe 
Wear-Levelling-Algorithmen zu fahren. Zumal sie unbegrenzten Zugriff auf 
Speicher haben. ;-)

Ansonsten bin ich erstaunt, dass f2fs so viel schneller als ext4 ist. 
Danke für die Daten.

Autor: Stefanus F. (stefanus)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
> Es waere trotzdem interessant zu erfahren,
> wann die Teile WIRKLICH sterben.

Das wird nicht viel nützen, denn die Wahrscheinlichkeit, dass du eine 
baugleiche Karte nach umfangreichen Test noch kaufen kannst, ist gering.

Autor: B. R. (bero)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
S. R. schrieb:
> SD-Karten (und deren Nachfolger SDHC und SDXC) sind laut Standard mit
> FAT16 (FAT32, exFAT) formatiert. Diese Formatierung kommt vom Hersteller
> und ist nicht identisch mit der Formatierung, die du da selbst drauf
> machst. Damit ist dein Test grundsätzlich schonmal außerhalb der
> Spezifikation.

Ja natuerlich. Es ist sogar so, dass vermutlich die "lebenslange 
Gerantie", die manche uSD Hersteller geben, erlischt, sobald man die uSD 
umpartitioniert oder umformatiert oder gar in einem Rpi einsetzt.

Deshalb auch die intensiven Tests. Ich will/wollte eine Karte finden, 
die

1) Schnell (genug) ist bei dem "ueblichen" Rpi load (random write mit 
kleinen Bloecken)
2) Eine Mindesmenge von 1TB Daten sicher schreiben kann
3) Stromausfaelle (waehrend schreiben) ueberlebt (muss ich noch testen)

> In so einer SD-Karte kann ein 8051 drin sein, oder ein ARM Cortex-M.
> Insbesondere letztere sind durchaus in der Lage, ziemlich komplexe
> Wear-Levelling-Algorithmen zu fahrHier sieht man das noch genauer:en. Zumal sie 
unbegrenzten Zugriff auf
> Speicher haben. ;-)

Ja, Cortex-M0 werden da angeblich neuerdings gerne verbaut. Und das 
ganze ist im Prinzip auch eine schoene Sicherheitsluecke (es gibt Leute, 
die auf dem uSD-Controller eigenen Code untergebracht haben - Link habe 
ich leider verlegt).

> Ansonsten bin ich erstaunt, dass f2fs so viel schneller als ext4 ist.
> Danke für die Daten.

Fuer kleine random writes ist das f2fs je nach uSD um einige Faktoren 
(!!) schneller als ext4 (das liegt an der Log-Struktur des f2fs). 
Sequentielles Lesen und Schreiben ist i.a. ein bisschen langsamer. Siehe 
auch hier fuer weitere Messwerte: 
Beitrag "Re: zuverlässige SD-Karte für Raspberry Pi"

Ausserdem bootet ein Rpi damit gut 5s schneller, weil das fsck entfallen 
kann. Das ist schon was wert, wenn man die Rpi-Bootzeit sonst noch 
ordentlich runteroptimiert hat.
Und durch die Log-Struktur gibt es auf FS-Ebene sozusagen ein 
kostenloses wear-Leveling.

SQLite hat uebrigens neuderdings eine spezielle Optimierung fuer f2fs, 
siehe 
https://www.phoronix.com/scan.php?page=news_item&p...

Ein kleiner Nachteil ist, dass etwas mehr vom FLASH fuer 
Verwaltungszwecke abgezwackt wird.

Autor: B. R. (bero)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan U. schrieb:
> Das wird nicht viel nützen, denn die Wahrscheinlichkeit, dass du eine
> baugleiche Karte nach umfangreichen Test noch kaufen kannst, ist gering.

Kommt auf die Karte an. Die Transcend TS8GUSDHC10U gibt es z.B. 
inzwischen seit ca. 3 Jahren, die Sandisk SDSQXAF-032G-GN6MA ca. 1 Jahr.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
B. R. schrieb:
> Ausserdem bootet ein Rpi damit gut 5s schneller,
> weil das fsck entfallen kann.

Wenn Journalling aktiviert ist, entfällt fsck doch ohnehin?
Oder nutzt du ext4 ohne Journal?

Autor: B. R. (bero)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Wenn Journalling aktiviert ist, entfällt fsck doch ohnehin?

Im Prinzip richtig, aber Raspbian setzt standardmaessig fsck.repair=yes 
in /boot/cmdline.txt und ich denke, das wird seine Gruende haben.

Ausserdem ist soweit ich weiss nur Metadaten-Journaling beim Raspbian 
eingestellt und mit diesen Einstellungen habe ich dann ext4 und f2fs 
auch verglichen.

Mit einem Daten-Journaling duerfte das ext4 noch weiter zurueckfallen, 
wohingegen das f2fs prinzipbedingt immer ein Datenjournaling macht.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achso. Danke für den Hinweis.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.