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
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.
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.
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.
Ich hatte bisher keine Probleme mit SD-Karten im RPi, auch Noname-Karten funktionieren. Aus dem Foto- und Smartphone-Bereich habe ich aber mittlerweile diese Erkenntnisse gewonnen: Finger weg von SanDisk (langsam beim Schreiben, Datenverlust nach dem "Auswurf" am Tablet). Die Evo- und Pro-Modelle mit dem plus-Zusatz von Samsung sind zwar teurer aber sauschnell und zuverlässig.
Nun jeder hat andere Erfahrungen mit Speicherkarten gemacht. Ich hab bislang welche von Sandisk und Transcend und bislang ist nach ~ 10 Jahren eine nun Kaputt gegangen mit "Sektorenfehler" von der Digicam. Hab da ein anderen PI wo eine Sandisk 4 GB drin ist der seit >1 Jahr im Dauerbetrieb läuft und keine Probleme macht. Aber wenn du auf Veranstaltung/Mobil ist wäre ggfs ein Banana Pi besser mit Sata Anschluss wo du eine SSD Verwendest. Beim Banana Pi hast du Modelle wo der Sata Port nicht wie beim Raspberry über USB Angebunden ist wodurch du nochmal etwas mehr Geschwindigkeit hast. Was aber meist der Fehler ist, ist durch den Transport die Speicherkarte/Stecker sich Lösen und so Kontaktprobleme entstehen. Wenn du es Sicher haben möchtest wäre ein zweiter schon gut als Online Spiegelung bzw ein zweiten Pi mit Speicherkarte der Startbereit ist und ein ext USB Stick wo die Daten extra nochmal gespeichert werden und du nur umstecken brauchst.
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.
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.
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.
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.
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...
@c-hater: Hast du dazu auch eine echte Quelle? Ja, man findet ein paar Hände voll Berichten im Netz dass SD-Karten bei Nutzung in Raspi korumpiert wurden, aber das hält sich in grenzen. Zudem scheint die Ursache meistens ein Powerloss während dem Schreibvorgang zu sein (also Abstecken vom Strom während geschrieben wird). Du machst dem TE grad unnötig ziemliche Angst >_> Er ist nicht der einzige der einen Raspberry für Echtzeit-Protokolierung von irgendwas nutzt. Das ist sogar eine der häufigsten Verwendungsmöglichkeiten des Raspberrys. @Phil: Das Ganze wird nicht physisch belastet, oder? Also der Raspberry wird nicht ständig bewegt o.ä.? Dann ist die Ausfallwahrscheinlichkeit grad während der Nutzungsperiode schon sehr gering. Weitreichende Statistiken welche SD-Karte im Raspberry am längsten lebt gibt es meines Wissens nach nicht - wohl einfach weil sie zu selten kaputt gehen. Allgemein kann man aber sicherlich empfehlen, nicht die günstigste zu nehmen und zumindest intuitiv würde ich schätzen, dass schnellere Karten auch robuster sein müssten (wahrscheinlich ist das aber ein Trugschluss, da wie schon erwähnt wurde, nicht das standardmäßige Dateisystem Verwendung findet). EDIT: Wenn du dir wirklich Gedanken machst, kannst du mal nach einer "SLC SD Card" suchen. Die sind technisch bedingt robuster (im Endefekt heisst dies dass sich eine 1 und eine 0, physikalisch mehr voneinander unterscheiden). Das ist wohl die Hauptdiferenz zu den "Consumer Karten" denn in Sachen Featurelevel ist inzwischen der Consumer Bereich auf dem selben Niveau. Ob sich das wirklich lohnt? Würde ich persönlich eher verneinen... Dann doch eher versuchen eine echte Redundanz zu schaffen. Statistisch ist menschliches Versagen (jemand kommt ans Kabel) ziemlich sicher wahrscheinlicher als der eigenständige Ausfall :D EDIT 2: Hier eine Suche: http://www.mouser.de/Semiconductors/Integrated-Circuits-ICs/Memory-Storage/Memory-Modules/Memory-Cards/_/N-9x4ns?P=1yy7k55Z1z0w1t4Z1yxxwsy Wobei ich leider nicht weiss was Panasonic wohl mit "SLC Lite" meint.
:
Bearbeitet durch User
Steffen schrieb: > Und ein USB Stick ist besser als eine SD-Karte oder denkst Du an eine > richtige Festplatte? Ich meine eine richtige Festplatte
Kai A. schrieb: > Nun jeder hat andere Erfahrungen mit Speicherkarten gemacht. Ich habe von meinen mal im Beitrag "Re: MIcroSD Karte durch Raspberry PI zerstört" berichtet. Alex G. schrieb: > Das ist wohl die Hauptdiferenz zu den "Consumer Karten" denn in Sachen > Featurelevel ist inzwischen der Consumer Bereich auf dem selben Niveau. Ich habe vorrangig die Erfahrung gemacht, dass eine gute Firmware den größten Effekt bringt. So waren die ersten Xmore-Karten, die als "industrietauglich" beworben wurden, schon nach 3-7 Tagen im Dauerschreibtest kaputt. Nach einer Reklamation wurde das Fehlerbild untersucht, die Firmware der Karten geändert (dass überhaupt jemand reagiert und was gemacht hat, war für mich ein ganz neues Erlebnis, andere Hersteller zeigten dort absolut keine Reaktion) und neue Muster beigestellt, die dann über ein dreiviertel Jahr liefen. Fazit: gleiche Hardware, andere Software --> Lebensdauer hundert mal größer. > Wenn du dir wirklich Gedanken machst, kannst du mal nach einer "SLC SD > Card" suchen. Ich habe hier teuere SLC "Industriequalitätskarten", die nach 2 Wochen Dauerbeschreiben schon kaputt sind. Wie gesagt: die Xmore "pseudoSLC" mit der richtigen Firmware halten ein dreiviertel Jahr. Samsung und Toshiba Consumer-TLC-Karten sind nicht viel schlechter... Dieser Dauerschreibtest läuft nun mit unterschiedlichen Karten seit ca. 3 Jahren und er wird auch die nächsten Jahre noch weiterlaufen. Derzeit sind gerade wieder Xmore-Karten drin, da dauert es aus obigen Gründen länger, als wenn die Karten nach 4 Wochen schon den Geist aufgeben.
:
Bearbeitet durch Moderator
Ja, wie wichtig Firmware ist, hat man durchaus schon bei SSDs sehr gut gesehen. "Wear-Leveling" und "Write Amplification" sind da gute Stichworte. Nur ist grade software etwas was man mit relativ geringem Aufwand, bzw. kaum Zusatzkosten, dann schnell auch in die Consumer Produkte bringen kann. Die paar Artikel die "Industrie SD Karten" anpreisen, die ich gefunden hab, sind inzwischen 5 Jahre oder älter. Deine Statistik ist in der tat interessant!
Alex G. schrieb: > Nur ist grade software etwas was man mit relativ geringem Aufwand, bzw. > kaum Zusatzkosten, dann schnell auch in die Consumer Produkte bringen kann. Allerdings kostet eben gute Software auch Geld und Zeit. Das erstere wäre nicht so schlimm, aber kein Hersteller wartet heute, bis die Software "fertig" und ausgereift ist...
Logisch. Ich ging nur davon aus dass der Hersteller eben bereits "Industrie Karten" mit der Firmware im Angebot hat. Btw. grad gemerkt in meinen 2 Raspis hab ich "Toschiba Exercia" Karten drin. Allerdings nutze ich die nicht in ausgiebigem Stil.
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...
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
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.
wendelsberg schrieb: > Ich verwende fuer meine Heizungssteuerung/Datenerfassung eine Datei in > /dev/shm also Ramdisk. Jede Nacht um 23:59 wird diese dann auf die > SD-Karte transferiert. Das verringert die Zahl der Schreibvorgaenge auf > 1/1440. > > mfG wendelsberg Sehr interessante Idee! Ja, wenn die Datenbank des TE darin ablegbar ist, könnte er die SD Karte im Betrieb ganz aus der Gleichung nehmen oder sie gar gänzlich nur als readable verwenden.
c-hater schrieb im Beitrag #5160972:
> BTW: postest du nebenbei auch mit anderen Accounts?
Nein.
:
Bearbeitet durch Moderator
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
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.
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.
Von den ganzen diversen-Pi Computertypen und Usern habe ich immer wieder gutes gehoert von "Samsung EVO(+)" MicroSD-Karten - und gleich danach Sandisk Ultra/Extreme. Die SanDisk Ultra und Extreme nutze ich und habe noch keine Ausfaelle. Auch 2 Lexar-Karten laufen hier gut.... Und auch eine "alte" (4 Jahre) Samsung Class 10, die vorher die 4 Jahre dienst im Smartphone tat und nun da im Smartphone eine neuere ist - diese ihren Dienst noch im Pi tun darf. Wenn ich dazu komme, sind die naechsten aber mal Sasmung EVO(+) 32GB
Schaut mal nach High Endurance Karten gibts von Sandisk, Lexar, Toshiba,... Kosten ein klein wenig mehr. In der config.txt gibt einen Parameter für den Takt zur SD Karte dort kann man 25,50,75 und 100 einstellen. Standard ist 50 meine Sandisk Karten funktionieren alle mit 100 nur die Thosiba macht nur 75 mit. Vielleicht bringt es ja etwas den Takt auf 25 runter zuschrauben. Ansonsten auch mal folgendes um weniger Schreibzugriffe zu haben. https://wiki.archlinux.de/title/Noatime
Alex G. schrieb: > Schau dir aber auch mal Wendelsberg's Ansatz an. Das wäre eine richtig > hübsche Lösung. Klappt natürlich nur wenn die Datenbank ohne Probleme in > den RAM passt. Und vor allem auch nur dann, wenn ein Stromausfall die Tagesdaten vernichten darf. Für eine Sportveranstaltung wäre das ziemlich doof.
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.
Phil schrieb: > Einziger Haken hierbei ist, das man ein wenig mehr Basteln muss als ein > fertiges Linux Image auf die SD Karte zu schreiben. Das kannst du im Zweifelsfall auch einmalig machen, daraus ein Image generieren und gut ist. Kann man auch für einen USB-Stick machen, um damit normale Notebooks zu befüttern, die sind im Zweifelsfall eher schnell verfügbar als ein RPi.
Phil schrieb: > Die RAM Geschichte schont sicher die SD Karte und wäre in einer > geschützen Umgebung sicher super, aber ich sehe die Gefahr, dass jemand > über das Kabel stolpert auch als nicht so klein an. Und wenn die Daten > dann nur im RAM sind ist alles vor dem letzten Sichern weg. Du sagtest ja in deinem Startpost Phil schrieb: > (Daten gingen keine verloren, > diese Werten zur Sicherheit live gedruckt.) Daher bin ich mal davon ausgegangen, es sei keine Speicherung nötig. Was SSD angeht - denke du musst nicht zwingend das OS darauf packen und ähnliche Umständliche Dinge. Es würde reichen, die Datenbank darauf zu packen.
Du kannst dein Linux auch komplett aus einer Ramdisk betreiben (d.h. die SD-Karte enthält nur Bootloader, Kernel und Initrd). Dann hast du auch garantiert keine Schreibzugriffe, die du nicht selbst veranlasst hast. Für Backups bzw. allgemeines Verwaltungsgedöns ist SQLite vermutlich besser geeignet als MySQL (weil die Datenbank in genau einer Datei liegt), aber ob man das von PHP aus ansprechen kann, weiß ich gerade nicht.
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.
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).
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
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
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.
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.
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.
> Du kannst dein Linux auch komplett aus einer Ramdisk betreiben
Dafür bräuchter der kleine Computer allerdings mehr RAM.
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
> 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.
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?
Meine Erfahrungen sind, das Karten gerne kaputt gehen, wenn Ihnen schlagartig die Spannung entzogen wird. Gerade beim RPI, wenn er einfach ausgesteckt wird, während er gerade von der Karte schreiben / lesen probiert. Da sind die USB Sticks besser geeignet. Ich vermute mal, das die USB Sticks intern noch über Kondensatoren verfügen, welche den BrownOut buffern.
Stefan U. schrieb: > Der Knackpunkt bei solchen Produktempfehlungen ist: Erst nach vielen > Monaten guter Erfahrung kann man eine Empfehlung aussprechen. Nicht unbedingt, denn ein Hersteller, der eine Firmware hat, wird die im Großen und Ganzen weiterverwenden. Und wie im Beitrag "Re: zuverlässige SD-Karte für Raspberry Pi" beschreiben, macht die Software gleich mal den Faktor 100 aus. Letztlich ist es so, dass alle von mir bisher getesteten Samsung- und Toshiba-Karten im Dauerschreibtest gut waren. Und alle z.B. vom Hersteller Intenso waren schlecht, oder eben gerade gut genug für die Kamera oder das Handy, wo man eine Speicherzelle nur ein paar mal beschreibt. Insofern empfehle ich jetzt jedem, der fragt einfach Samsung-Karten (und verwende die auch selber). Fred R. schrieb: > Meine Erfahrungen sind, das Karten gerne kaputt gehen, wenn Ihnen > schlagartig die Spannung entzogen wird. Wie definierst du "schlagartig"? > während er gerade von der Karte schreiben ... probiert. Das geht sowieso schief, denn das ist ja wie ins fahrende Auto einzusteigen. Da kannst du froh sein, wenn die Karte beim nächsten Booten noch ihre Firmware findet. Die ist nämlich auch auf dem Flash gespeichert...
Fred R. schrieb: > Da sind die USB Sticks besser geeignet. > Ich vermute mal, das die USB Sticks intern noch über Kondensatoren > verfügen, welche den BrownOut buffern. Wenn du einen USB-Stick oder eine SD-Karte im Betrieb rausziehst, werden die Datenleitungen vor den Versorgungsleitungen getrennt, was dem Controller etwas Zeit gibt. Das ist eine Folge der Hotplug-Fähigkeit. Das gilt aber nicht, wenn du die Versorgung kappst, weder für SD-Karten noch für USB-Sticks. Und dann können beide gleichermaßen kaputt gehen. Technisch sind sich beide ohnehin sehr ähnlich.
S. R. schrieb: > Wenn du einen USB-Stick oder eine SD-Karte im Betrieb rausziehst, werden > die Datenleitungen vor den Versorgungsleitungen getrennt, was dem > Controller etwas Zeit gibt. Das bringt alles nichts, wenn eine 1MB große Datei geschrieben werden soll und erst 500kB übertragen sind...
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...
c-hater schrieb: > Es geschehen noch Zeichen und Wunder... Dass wir beide mal einer Meinung > wären, hätte ich echt nicht gedacht. Solange du es schaffst, den dritten Buchstaben des Alphabets nur in inniger Verbindung mit anderen Buchstaben zu nutzen... ;-)
S. R. schrieb: > Wenn du einen USB-Stick oder eine SD-Karte im Betrieb rausziehst, werden > die Datenleitungen vor den Versorgungsleitungen getrennt, was dem > Controller etwas Zeit gibt. Das ist eine Folge der Hotplug-Fähigkeit. > > Das gilt aber nicht, wenn du die Versorgung kappst, weder für SD-Karten > noch für USB-Sticks. Und dann können beide gleichermaßen kaputt gehen. > Technisch sind sich beide ohnehin sehr ähnlich. Korrekt. Abhilfe kann da eine USB schaffen, von denen es für den RasPi eine ganze Reihe gibt. Die erkennt einen Stromausfall, puffert ihn mit ihrem Akku ab und veranlasst den Pi, geordnet herunterzufahren. Ansonsten kann man jede moderne Datenbank wie MySQL, PostgreSQL entweder in einem HA-Cluster betreiben, oder sogar als geshardeten und replizierten DC-Cluster (etwa PostgreSQL-XL). Die meisten NoSQL-Datenbanken sind sogar von vorneherein dafür ausgelegt.
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.
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.
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.
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: https://www.youtube.com/watch?v=ruEn7TE4YMM 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-intel-core-2-duo-su9600-2x-1-6ghz-14303.html
Beitrag #5163593 wurde vom Autor gelöscht.
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-intel-core-2-duo-su9600-2x-1-6ghz-14303.html 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.
Die neueren Raspberries können auch ganz ohne SD aus dem Netz booten: https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/net_tutorial.md Braucht man natürlich einen Server, dafür könnte man den o.g. Laptop nehmen.
> 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.
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..)
Phil schrieb: > camikusch schrieb: > https://www.itsco.de/notebook-dell-latitude-e4200-intel-core-2-duo-su9600-2x-1-6ghz-14303.html > > 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
Den RPI3 kann man von USB Platte oder Stick starten! Verwende meine Sticks jetzt schon ewig und hatte bis jetzt noch nie Probleme. Man soll halt nur nicht die aus einem Schütgutregal eines Diskounters verwenden. *Ja. Zwanzig Leute wissen es jetzt sicher besser, dass man von USB NICHT starten kann sondern nur von der SD Karte. Aber was sagt die offizielle RPI Seite dazu? https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/msd.md
:
Bearbeitet durch User
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.
> 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.
20TB schrieb: > Wenn so 'ne SD Karte übern Jordan geht, hängt dann das gesammte Linux > oder wird ein "medium error" wie bei den HDDs gemeldet? Im Betrieb ist mir bisher keine gestorben, aber kaputte SD-Karten werfen meistens eindeutige Meldungen oder es passiert schlicht überhaupt nichts. Eine Karte hat mir aber das System blockiert, bis ich sie wieder rausgezogen hatte (im Laptop-eigenen Kartenleser).
Stefan U. schrieb: > Wir sind nicht blöde. Das wurde auch nirgends behauptet... > Es geht natürlich um den verlust der bereits > geschriebenen Daten, insbesondere der Dateien, die abgeschlossen wurden. Das ist übrigens einer der Effekte von "schlechten" Karten: Dateien, die nur 1x geschrieben und ab dann nur noch gelesen werden, sind auf einmal korrupt. Das fiel hier bei Sprachdateien auf, die Meldungen in verschiedenen Sprachen gespeichert hatten: nach und nach tauchten seltsame Texte mit falschen Buchstaben auf. Ein Vergleich der Dateien mit den Ausgangswerten zeigte dann, dass einzelne Bits in Richtung '1' umgekippt waren. Das ist das erste Zeichen für das baldige Ende der Karte. Und wenn letztlich in der (ebenfalls statischen) Programmdatei einzelne Bits umkippen, dann passiert alles Mögliche... :-o
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.
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.
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.
1 | iozone Raspi3 |Typ|Typennummer |EurEx|RRND| WRND |Bmrkg |
2 | ---------------------------+---+------------------+-----+----+------+-------- |
3 | Sandisk Extreme 32GB V30 |uSD|SDSQXAF-032G-GN6MA| 16.0| 8.1| 3.8 | |
4 | Samsung Evo+ 32GB |uSD|MB-MC32DA | 12.5| 8.1| 2.9 |Auslauf |
5 | Samsung Evo UHS-I 16GB |uSD|MB-MP16D | 10.8| 5.5| 1.2 | |
6 | Adata Premier 16GB |uSD|AUSDH16GUICL10-R | 6.8| 6.8| 1.1 | |
7 | Transcend Ult. U3 V30 |uSD|TS16GUSDU3M | 14.9| 5.4| 0.9 | |
8 | Transcend Ult. 600x 8GB |uSD|TS8GUSDHC10U1 | 6.5| 6.5| 0.8 | |
9 | Verbatim Pro U3 16GB |uSD|47040 | 11.0| 7.1| 0.8 | |
10 | Samsung Evo Plus 32GB |uSD|MB-MC32GA | 11.2| 4.5| 0.8 | |
11 | Sandisk Ultra 32GB |uSD|SDSQUAR-032G-GN6MA| 12.1| 5.7| 0.6 | |
12 | Samsung Evo UHS-I 32GB |uSD|MB-MP32DA | 12.4| 4.2| 0.7 | |
13 | xlyne SDHC 8GB |uSD|7408001 | 5.4| 5.4| 0.4 | |
14 | Toshiba Exceria M302-EA 32G|uSD|THN-M302R0320EA | 9.5| 5.9| 0.2 | |
15 | Toshiba Exceria M302-EA 16G|uSD|THN-M302R0160EA | 6.7| 5.8| 0.2 | |
16 | ---------------------------+---+------------------+-----+----+------+-------- |
17 | SanDisk UltraFit V2 32GB |USB|SDCZ43-032G-GAM46 | 11.5| 5.4| 3.4 |60 Grad! |
18 | SanDisk UltraFit V2 16GB |USB|SDCZ43-016G-GAM46 | 8.0| 4.6| 2.5 |60 Grad! |
19 | Intenso Slim Line 3.0 16GB |USB|3532470 | 7.4| 3.8| 0.5 | |
20 | Verbatim Nano 16GB |USB|98709 | 10.0| 4.0| 0.5 | |
21 | Toshiba TransMem U364 32GB |USB|THN-U364W0320E4 | 10.5| | |Abbruch |
22 | |
23 | flashbench Raspi3 f2fs |Typ|Typennummer |EurEx|RSEQ|WSEQ|RRND|WRND |
24 | ------------------------+---+------------------+-----+----+----+----+---- |
25 | Sandisk Extreme 32GB V30|uSD|SDSQXAF-032G-GN6MA| 16.0|19.7|19.2| 9.0|19.0 |
26 | Transcend Ult. 600x 8GB |uSD|TS8GUSDHC10U1 | 6.5|21.5|13.1| 5.7|13.5 |
27 | Adata Premier 8GB |uSD|AUSDH8GUICL10 | 5.7|17.8| 7.5| 6.0| 8.7 |
28 | xlyne SDHC 8GB |uSD|7408001 | 5.4|14.3|10.9| 4.4| 8.0 |
29 | |
30 | flashbench Raspi3 ext4 |Typ|Typennummer |EurEx|RSEQ|WSEQ|RRND|WRND |
31 | ------------------------+---+------------------+-----+----+----+----+---- |
32 | Sandisk Extreme 32GB V30|uSD|SDSQXAF-032G-GN6MA| 16.0|21.9|20.6| 9.3| 6.8 |
33 | Transcend Ult. 600x 8GB |uSD|TS8GUSDHC10U1 | 6.5|21.5|14.5| 5.9| 1.4 |
34 | Adata Premier 16GB |uSD|AUSDH16GUICL10-R | 6.8|21.6| 9.8| 5.6| 1.5 |
35 | 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
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.
1 | Speichermedium mit f2fs |typ|ui |
2 | -----------------------------------------+---|--- |
3 | Sandisk Extreme 32GB (SDSQXAF-032G-GN6MA)|uSD|18s |
4 | Adata Premier 16GB (AUSDH16GUICL10-R ) |uSD|17s |
5 | Transcend Ult. 600x 8GB (TS8GUSDHC10U1) |uSD|19s |
6 | xlyne SDHC 8GB (7408001) |uSD|20s |
7 | |
8 | Speichermedium mit ext4 inkl. fsck |typ|ui |
9 | -----------------------------------------+---|--- |
10 | Sandisk Extreme 32GB (SDSQXAF-032G-GN6MA)|uSD|25s |
11 | Adata Premier 16GB (AUSDH16GUICL10-R ) |uSD|25s |
12 | Transcend Ult. 600x 8GB (TS8GUSDHC10U1) |uSD|26s |
P.S.: Sorry fuer das crosspost, hatte den Artikel zunaechst unabsichtlich als "Neuer Beitrag" eingestellt.
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
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.
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.
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.
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...
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?
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
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.
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.
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 ;-)
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/fast15/fast15-paper-lee.pdf) dann wird auch schnell klar, wieso.
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.
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&px=SQLite-3.21-Released 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.
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):
1 | flashbench Raspi3 ext4 | Typennummer |RSEQ|WSEQ|RRND|WRND |
2 | ------------------------+--------------------+----+----+----+---- |
3 | Sandisk Extreme 32GB V30| SDSQXAF-032G-GN6MA |21.9|20.6| 9.3| 6.8 |
4 | 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)
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% ;-)
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.
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
Hier mal die iozone Messwerte einer Samsung Evo+ 32GB" (nicht "plus"):
1 | kB reclen write rewrite read reread rnd-rd rnd-wr |
2 | 1: 102400 4 1281 1751 5695 5695 5604 1800 |
3 | 2: 102400 4 1448 1345 5642 5643 5551 827 |
Bereich 1: selten beschrieben Bereich 2: oft beschrieben fs: ext4
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.
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.
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.
Thomas schrieb: > Das nenne ich eine messerscharfe Analyse. Du hast bestimmt Abitur. Das geht auch ohne Abitur. Und es ist ohne firmeninternes Wissen zu haben die einzige realistische Methode. Siehe dazu den Beitrag "Re: zuverlässige SD-Karte für Raspberry Pi" Hast du eine bessere Teststrategie oder willst du nur auch mal irgendwas zum Thema gesagt haben?
Thomas schrieb: > Das nenne ich eine messerscharfe Analyse. Wollte es nur einfach darstellen, damit Du es auch verstehst ;-) > Du hast bestimmt Abitur. Noch schlimmer: Zusaetzlich noch 2 Ingenieurdiplome und > 25 Jahre Berufserfahrung in beiden Branchen. Spass beiseite: Wenn Du eine bessere Idee hast, wie man die Haltbarkeit verschiedener SD-Karten wenigstens grob klassifizieren kann, als mit einem der entsprechenden Anwendung analogen Schreibmuster die Dinger kaputtzumachen, dann immer her damit.
Die "plus" waere dann schon neu nur auf dem level Deiner viel beschriebenen "+". Mag mir den Rest gar nicht weiter vorstellen.... Dabei ist die "plus" der Nachfolger der "+" und laut Aufdruck noch schneller (und auch teurer). Naja, im Fotoapparat vielleicht. Echt schade, die "+" haette mir sehr gut in den Kram gepasst. So bleibt mir auf diesem Leistungslevel nur noch die (nochmal deutlich teurere) "SanDisk Extreme 32GB" (ohne "Pro" !!!) uebrig.
Thema: uSD totschreiben ======================= Bin nun seit einiger Zeit dabei, erst mal die billige xlyne SDHC 8GB (7408001) mit ext4 (noatime, ordered) totzuschreiben. Das mache ich auf einer 5GB Datenpartition (die restlichen 2.4GB sind ebenfalls partitioniert und mit ext4 formatiert, sodass sie von der uSD nicht zum wearleveling herangezogen werden koennen). * Rpi startet vom USB-Stick, da ist die Testsoftware drauf * Testprogramm erstellt auf uSD eine 1MB Datei macht folgendes: * 1MB 0x55 schreiben (Posix write) * fsync (Posix) * 1MB lesen und pruefen, ob 0x55 drin steht (Posix read) * 1MB 0xAA schreiben (Posix write) * fsync (Posix) * 1MB lesen und pruefen, ob 0xAA drin steht (Posix read) Diverse Logs ueber den Verlauf werden auf den USB-Stick geloggt. Inzwischen wurden ca. 1GB Daten (also 1024 x 1MB) geschrieben, also jeder Sektor der Datei eben 1024 mal. Die uSD zeigt keinerlei Probleme, nicht mal die Datenrate ist zurueckgegangen (konstant bei ca. 3.7MB/s schreiben+lesen). Das ist schon eine (angenehme) Ueberraschung. Hat jemand eine Idee, ob nicht doch irgend ein Fehler im Testalgorithmus stecken koennte? Dem fsync sollte man wohl trauen koennen, sonst ist sowieso alles verloren ;-) .
Bernhard R. schrieb: > Dem fsync sollte man wohl trauen koennen, sonst ist sowieso alles > verloren ;-) . Dem fsync() kannst du soweit trauen, dass dein Linux die Daten an die SD abgegeben hat. Ob die Daten dann auch im Flash sind, ist nicht garantiert, aber relativ wahrscheinlich (sonst wäre die Datenrate höher). Außerdem kann es sein, dass dein Linux die Daten aus dem Plattencache liest und nicht vom Device. Deine Testdatenmenge ist kleiner als ein Eraseblock, der Controller wird also deine gesamte Datei cachen (und möglicherweise auch die inode-Zugriffe). Die Chancen stehen dadurch äußerst gut, dass du deine Antwort aus diesem Cache beziehst, nicht aus den real im Flash gespeicherten Bits - wenn Linux überhaupt von der Karte liest. Du beschreibst immer nur die gleichen Blöcke des Devices, also hast du den optimalen Fall für das Wear-Levelling. Deine Testdatei wird also schön gleichmäßig durch den gesamten Flash wandern. Es gibt zwar ein wenig Write Amplification (weil überall ein Dateisystem drauf ist), aber ob die eigentlichen Datenbereiche deines Dateisystems vom Controller als "leer" angesehen werden (mke2fs nutzt standardmäßig TRIM) oder nicht, kann ich nicht einschätzen. Aus meiner Sicht betreibst du ein beinahe-best-case-Schreibszenario und wirst Fehler erst nach einem Reboot feststellen. Deine Datenmenge ist zu klein.
Vielen Dank fuer den Input, hat mir einige Ansaetze zum Nachdenken gegeben. Ich bin wie Du sehr sicher, dass fsync die Daten wirklich auf die uSD schreibt, dafuer gibt es etliche Hinweise und keinen, der dagegen spricht. Was ich nicht bedacht habe ist, dass aufgrund der "kleinen" Dateigroesse von 1MB die gelesenen Daten vermutlich wirklich aus dem Cache kommen und das Ruecklesen damit eher wertlos ist. Das hat aber mit dem Schreiben selbst nichts zu tun und ich kann ja zwischendurch mal rebooten um zu sehen, ob die Datei noch in Ordnung ist (habe ich auch schon gemacht, es ist noch immer alles in Ordnung). In der Sache mit TRIM hast Du aber (leider) recht. Die "discard" Option ist zwar beim mount default ausgeschaltet, ich hatte aber bisher nicht gewusst, dass mkfs.ext4 beim FORMATIEREN "discard" defaultmaessig eingeschaltet, also ein einmaliges TRIM macht. Vielen Dank nochmal fuer diese sehr wertvolle Information! Das heisst also, dass alleine durch das formatieren dem uSD Controller mitgeteilt wird, welche Sektoren vom Filesystem erst mal nicht benutzt werden (und das sind fast die gesamten 8GB, da meine Testdatei ja nur 1MB gross ist). Diese Sektoren kann der uSD Controller zum werar leveling heranziehen. Ob die uSD Karte das TRIM akzeptiert und ob daraus folgend wirklich ein wear leveling gemacht wird, haengt von der uSD Karte ab. Angesichts der der grossen problemlos geschriebenen Datenmenge von 1TB gehe ich fuer meine Testkarte davon aus. Allerdings ist der Test nicht ganz wertlos, immerhin wurden tatsaechlich 1TB Daten geschrieben. Trotz vermutetem wear leveling wurde jeder Sektor also bisher mindestens 128 mal (1024/8) beschrieben, so schlecht ist das nicht fuer diese billige Karte. Beachten sollte man jedenfalls, dass das wear leveling nur gut funktioniert, wenn genug unbenutzte Sektoren vorhanden sind. Der alte, aber gute Trick, eine mehrfach groessere Karte zu verwenden, als man letztlich Daten draufschreiben will, hat also durchaus seine Berechtigung. Das gilt AUCH fuer das f2fs. Da man aber nie sicher sein kann, ob die uSD TRIM und damit das wear leveling wirklich unterstuetzt, rate ich trotzdem nach wie vor zum f2fs, das durch die log-Struktur ein wear leveling quasi auf FS-Ebene eingebaut hat (und es schreibt kleine random Daten um Faktoren schneller, das ist bei einer DB Anwendung wichtig). Ich werde meinen Test nun so abaendern, dass ich die Partition(en) mit "nodiscard" neu formatiere. Somit kann die uSD maximal noch mit eventuell vorhandenen Reservesektoren wear leveling machen (was auch ok ist). Alternativ koennte man eine zweite Testdatei anlegen, die das ganze FS fuellt. Auch in diesem Fall kann die uSD nur noch mit den Reservesektoren wear leveling betreiben. Das Problem mit dem ruecklesen aus dem Cache muss ich noch loesen, damit ich zuverlaessig, rechtzeitig und automatisch den Tod der Karte feststellen kann. Einwaende?
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.
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.
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.
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.
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.
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
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.
soul e. schrieb: > Das ist das, was ich als "umkopieren" bezeichnet habe Der Controller kopiert aber nichts um. Das was du hier (siehe unten) beschrieben hast, macht nicht der Controller für den Nand-Speicher und auch nicht das wear-leveling. Das ist schlicht falsch, so wie du es beschrieben hast. soul e. schrieb: > Zum Tauschen sind drei Schreibvorgänge notwendig: A-->temp, B-->A, > temp-->B.
900ss D. schrieb: > Der Controller kopiert aber nichts um. > Das was du hier (siehe unten) beschrieben hast, macht nicht der > Controller für den Nand-Speicher und auch nicht das wear-leveling. Das > ist schlicht falsch, so wie du es beschrieben hast. Das wäre allerdings imho die einzige Möglichkeit (und technisch einfach zu realisieren) um den Ausfall der Zellen zu verhindern. Hast du eine Quelle dafür, dass kein Controller so vorgeht? ;-)
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.
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.
Servus miteinander, sehr interessantes Thema wie ich finde und danke an Bernhard erstmal für die Arbeit. Ich hatte den gleichen Gedanken wie soul eye soul e. schrieb: > Es werden häufig geschriebene mit Userdaten belegte Blöcke gegen > seltener beschriebene mit Userdaten belegte Blöcke getauscht. und auch wenn der Einwand von 900ss 900ss D. schrieb: > Der Controller kopiert überhaupt keine Blöcke um. Das wäre viel zu > uneffektiv. Der Wearleveling-Algorithmus benutzt für einen logischen > Block X einfach unterschiedliche physikalisch Blöcke. Aber es wird > niemals der Inhalt umkopiert. mit Sicherheit berechtigt ist, ändert es dennoch nichts an der Tatsache, dass der uSD-Controller dem Benutzer lediglich logische Adressen gibt und die physikalischen Adressen sich ändern können wie er (der Controller) es für richtig hält. D.h. meiner Meinung nach trifft folgendes nicht zu Bernhard R. schrieb: > die restlichen 2.4GB sind ebenfalls > partitioniert und mit ext4 formatiert, sodass sie von der uSD nicht zum > wearleveling herangezogen werden koennen Der Zusammenhang zwischen uSD, deren Partitionierung und FAT32 als Dateisystem ergibt sich - soweit ich das verstehe - daraus, dass die Dateisystemtabelle (FAT) an einer logischen Adresse liegt, welche gesondert behandelt wird. Das ist in sofern sinnvoll, da Änderungen am Dateisystem häufig vorkommen. Zu diesem Zweck mappen die uSD-Controller diese logische Adresse wenn möglich in einen Speicher, welcher aus SLC-Speicherzellen besteht und somit zum einen höhere Schreib- und Leseraten erlaubt und zum anderen häufiger beschrieben werden kann. Das grundsätzliche Problem, was den Einsatz einer uSD in RPi und Co angeht sehe ich darin, dass diese Geräte typischerweise mindestens zwei (und normalerweise noch mehr) Partitionen besitzen, wofür die SD-Karten an sich nie ausgelegt waren. Hier sind noch zwei Quellen zu dem Thema: http://3gfp.com/wp/2014/07/formatting-sd-cards-for-speed-and-lifetime/ http://wiki.laptop.org/go/How_to_Damage_a_FLASH_Storage_Device
Es gibt zwei war leveling Methoden. Static Wear leveling und dynamic Wear leveling oder auch mixed. Beim static Wear leveling werden tatsächlich Blöcke umkopiert. Findet aber in Sd-Karten eher nicht statt. Bei z.B. SSDs schon. Das soll verhindern, dass die Blöcke mit "alten" Daten auch beim wear leveling berücksichtigt werden. Die würden ja sonst dem Algorithmus nicht zur Verfügung stehen und so die Gesamtlebensdauer des Speichers verringern will weniger Blöcke genutzt werden können. Also ich korrigiere meine Aussage insoweit, dass in SD-Karten nicht umkopiert wird. Um diesen Speicher geht es hier ja.
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.
900ss D. schrieb: > Also ich korrigiere meine Aussage insoweit, dass in SD-Karten nicht > umkopiert wird. Um diesen Speicher geht es hier ja. Nehmen wir den hypothetischen Fall an, dass (1) eine Page einem Block entspricht und dass (2) lediglich ein Block reserviert ist (zusätzlich zum nach außen sichtbaren logischen Adressraum). Wenn nun der Client immer den gleich LBA schreibt, müsste der reservierte Block beschrieben werden. Der (alte) Block, der dem LBA vorher zugeordnet war, wird zum neuen (freien) reservierten Block. Beim nächsten Schreibzugriff auf den selben LBA passiert das gleiche. Usw. usf. Es würden also ständig nur zwei Blöcke beschrieben, was zum baldigen Ableben führen würde. In der Praxis ist das etwas komplexer, aber imo mit einem ähnlichen Effekt. Woher kommt deine Annahme, dass keine SD-Card Software das (durch umkopieren) abfängt. Ich kann mir durchaus vorstellen, dass es Software gibt, die das nicht macht. Aber die Behauptung, dass es das auf SD-Card grundsätzlich nicht gibt, irritiert mich etwas.
Bernhard R. schrieb: > Das mache ich auf einer 5GB Datenpartition (die restlichen 2.4GB sind > ebenfalls partitioniert und mit ext4 formatiert, sodass sie von der uSD > nicht zum wearleveling herangezogen werden koennen). Dir sollte eines klar sein: du kannst auf diese rein logische und völlig abstrakte Weise nicht steuern, welcher Teil des physikalischen Flashs mit welchen Daten beschrieben wird. Bernhard R. schrieb: > Beachten sollte man jedenfalls, dass das wear leveling nur gut > funktioniert, wenn genug unbenutzte Sektoren vorhanden sind. Wobei "ungenutzt" nicht "ohne Inhalt und Information" bedeutet. Es reicht z.B. schon aus, wenn Teile des Flashs mit statischen Daten belegt sind. Denn die werden dann einfach in einen schon häufig benutzen Block verschoben und voilà: ein leerer und fast unbenutzter Block ist entstanden...
:
Bearbeitet durch Moderator
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
Mikro 7. schrieb: > Es würden also ständig nur zwei Blöcke beschrieben, was zum baldigen > Ableben führen würde. Du hast es nicht richtig verstanden. Das wear-leveling nutzt alle Blöcke, die frei sind. Reserveblöcke werden in der Regel vom BBM (bad block management) genutzt, wenn ein Block als defekt erkannt wird (erase schlägt fehl, program schlägt fehl, Daten werden mehrfach mit korrigierbaren Fehlern gelesen oder nicht korrigierbare Daten werden gelesen). In der Regel sind Wear-leveling und BBM zusammen im Flash Management Layer (FML) untergebracht. Wenn es natürlich nur noch einen freien Block geben sollte, hast du Recht.
Es gibt genug Papers im Netz dazu, allerdings keine expliziten Algorithmen. Die sind gut geschützt. Es ist wirklich ein spannendes Thema finde ich.
:
Bearbeitet durch User
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?
Lothar M. schrieb: > Dir sollte eines klar sein: du kannst auf diese rein logische und > völlig abstrakte Weise nicht steuern, welcher Teil des physikalischen > Flashs mit welchen Daten beschrieben wird. Dass man (das OS, das FS) nur logische Sektoren ansprechen kann, ist klar. Anders waere ein waer leveling sowieso kaum machbar. Du uebersiehst aber einen entscheidenden Punkt: Es geht letztlich um die GROESSE des Datenbereiches, nicht um seine Lage. Wenn die Karte 8GB hat, die 8GB mit einem Filesystem belegt sind und das OS dem Controller nicht mitteilt, welche Sektoren keine Daten enthalten (siehe TRIM), wird es fuer den uSD Controller sehr schwer mit dem wear leveling. Genau das war auch der Ausgangspunkt, dass ich versuche, eine Karte absichtlich kaputtzuschreiben, also moeglichst unguestig zu belasten. Einfach um zu sehen, wie lange sie beim "worst case" durchhaelt. Das ist fuer mich ein wichtiger Aspekt, denn gerade bei Verwendung einer uSD in einem Raspi gehe ich davon aus, dass der worst case vielleicht doch mal unbemerkt eintritt. Wenn eine Karte das wear leveling dann besser macht als von mir unterstellt und laenger haelt: Gerne! > Wobei "ungenutzt" nicht "ohne Inhalt und Information" bedeutet. Es > reicht z.B. schon aus, wenn Teile des Flashs mit statischen Daten belegt > sind. Denn die werden dann einfach in einen schon häufig benutzen Block > verschoben und voilà: ein leerer und fast unbenutzter Block ist > entstanden... Ich kann mir nicht vorstellen, dass so ein uSD Controller DARUEBER auch noch Buch fuehrt. Vielleicht bei einer SSD, aber nicht bei einer (billigen) uSD, die noch dazu "auf Fotoapparate optimiert" ist. Nicht falsch verstehen, WENN die uSD Controller so intelligent waeren, umso besser. Ich denke aber, dass deren wear leveling nur SEHR rudimentaer ist. Bis vor wenigen Jahren gab es uSD Karten, die sowas ueberhaupt nicht hatten. Was ich will ist, die worst case "Haltbarkeit" fuer ein paar wenige spezielle Typen (die ich eben zukuenftig einzusetzen gedenke) abzuschaetzen. Zum einen zum Vergleich dieser Kartentypen und zum anderen, um ruhiger schlafen zu koennen :-)
Karl schrieb: > Irgendwo muss sich der Controller merken, wie oft er welche Blöcke > beschrieben hat, und das ausfallsicher. Welchen Speicher nutzt er denn > dafür, der muss ja mindestens so robust sein wie der Flash? Eeprom? Das geht im Prinzip schon, einfach einen kleinen Metadatenbereich (ein paar Bytes) im Block reservieren und dort einen Schreibzaehler unterbringen, der zusammen mit den Daten bei jedem Loesch+Schreib Vorgang aktualisiert wird. Z.B. bei kleineren SPI-Nor Flash (um die es hier nicht geht, aber es geht ums Prinzip) ist es oft so, dass pro Block ein paar Bytes mehr zur Verfuegung stehen (z.B. AT45DB Dinger, 528 Byte statt 512 pro Page), damit man schoene 2er Potenzen fuer den Datenbereich hat und man wirklich die angegebene Groesse rein fuer Nettodaten zur Verfuegung hat. Das habe ich selbst schon praktisch genau so in einer Anwendung gemacht. Woran ich zweifle ist, dass die uSD Controller intelligente und ausgefuchste wear leveling Algorithmen haben. Woran ich noch mehr zweifle ist, dass die fuer Fotoapparate gedachten Consumer Karten gut geeignet sind fuer Rpi Anwendungen. Deshalb versuche ich herauszufinden, ob ein paar der Kartentypen, die ich ins Auge gefasst habe (weil das Preis/Leistungsverhaeltnis ungefaehr passt), ZUVERLAESSIG GENUG sind fuer die Verwendung im Rpi. Das ist auch ueberhaupt Ursprung des ganzen Thread, der da heisst: zuverlässige SD-Karte für Raspberry Pi Es geht also nicht darum, was moeglich waere oder was die eine oder andere Karte oder SSD macht, sondern wie zuverlaessig einige uSD Karten sind in einem Einsatzfeld, fuer das sie nie vorgesehen waren.
Eine Bitte! Da mir der Thread etwas abgeschweift erscheint, moechte ich der geneigten Leserschaft eine Bitte unterbreiten: Und zwar, von allzu akademischen und theoretischen Betrachtungen Abstand zu nehmen und Vorschlaege zu machen, wie ich es eurer Meinung nach schaffen kann, eine uSD Karte mit ext4 (noatime) moeglichst schnell kaputtzuschreiben. Die Algorithmen sollten wenn moeglich nahe am Nutzungsmuster eines Rpi liegen (naja, wie auch immer das aussehen mag). Bitte auch um ein paar Angaben, warum ihr glaubt, dass euer Algorithmus es am schnellsten schafft, die Karte totzukriegen. Ich habe natuerlich selbst auch schon eine Idee, will aber nicht vorgreifen oder beeinflussen. Gerne greife ich das aussichtsreichste Verfahren auf, lasse es auf ein paar der uSD Karten aus dem Haufen hier neben mir los und poste dann die Ergebnisse. Anschliessend habe ich vor, die gleichen Kartentypen nochmals mit f2fs mit den gleichen Algorithmen zu quaelen und wieder die Ergebenisse hier zu posten.
:
Bearbeitet durch User
Karl schrieb: > Irgendwo muss sich der Controller merken, wie oft er welche Blöcke > beschrieben hat, und das ausfallsicher. Welchen Speicher nutzt er denn > dafür, der muss ja mindestens so robust sein wie der Flash? Eeprom? Er nutzt dazu den ohnehin vorhandenen Flash. Bei eMMC (technisch äquivalent zur SD-Karte) ist da auch die Firmware des Controllers drauf. Dazu gibt's einen Vortrag vom 34c3. Ein paar zig MB Größenunterschied bei verschiedenen 8 GB-Karten merkst du sowieso nicht. B. R. schrieb: > Wenn die Karte 8GB hat, die 8GB mit einem Filesystem belegt sind > und das OS dem Controller nicht mitteilt, welche Sektoren keine > Daten enthalten (siehe TRIM), wird es fuer den uSD Controller sehr > schwer mit dem wear leveling. Die Chancen stehen gut, dass auf deiner 8 GB-Karte insgesamt 16 GB-Flash verbaut sind, von denen ein gewisser Anteil schon ab Herstellung defekt ist. Wenn 10 GB zuerlässig arbeiten, hast du 2 GB an Reservesektoren (eine 10 GB-Karte lässt sich nicht verkaufen). B. R. schrieb: > Deshalb versuche ich herauszufinden, ob ein paar der Kartentypen, die > ich ins Auge gefasst habe (weil das Preis/Leistungsverhaeltnis ungefaehr > passt), ZUVERLAESSIG GENUG sind fuer die Verwendung im Rpi. Da gelten noch andere Randbedingungen, wie z.B. das Verhalten bei Stromausfall ohne Entnahme. Bei Hot-Unplug hat der Controller genug Zeit, um die Daten wegzuschreiben (die Power-Pins sind länger), bei Stromausfall im Sockel nicht. Die dann manchmal entstehenden Fehler sind für dich unvorhersehbar und werden nur von Dateisystemen mit Prüfsummencheck über Daten und Metadaten erkannt. Durch "wear-levelling durch den gesamten Flash" kann z.B. auch eine unbeteiligte, readonly gemountete Partition kaputtgehen. Darauf testest du z.B. auch nicht. B. R. schrieb: > Und zwar, von allzu akademischen und theoretischen Betrachtungen Abstand > zu nehmen und Vorschlaege zu machen, wie ich es eurer Meinung nach > schaffen kann, eine uSD Karte mit ext4 (noatime) moeglichst schnell > kaputtzuschreiben. a) Das Dateisystem maximal groß machen. b) Die Testdatei maximal groß machen. c) Die Testdatei mit einer Pseudozufallsfolge am Stück von vorn bis hinten beschreiben. d) Die Testdatei am Stück auslesen und vergleichen. e) Wiederhole c) und d) ad nauseam.
S. R. schrieb: > a) Das Dateisystem maximal groß machen. > b) Die Testdatei maximal groß machen. > c) Die Testdatei mit einer Pseudozufallsfolge am Stück von vorn bis > hinten beschreiben. > d) Die Testdatei am Stück auslesen und vergleichen. > e) Wiederhole c) und d) ad nauseam. Das dürfte allerdings ewig dauern und stellt auch weider nicht das mehr oder weniger reale Problem dar, dass die Karten durch Datenbanken oder Logging aussteigen. Das große problem ist noch immer ob mand avona usgehen kann, ob überhaupt Wear Leveling aktiv ist. Dass die Micro-SD karten das inzwischen überhaupt haben, war mir neu! Schön dass die Industrie das nicht mehr auf SSDs beschränkt.
S. R. schrieb: > a) Das Dateisystem maximal groß machen. > b) Die Testdatei maximal groß machen. > c) Die Testdatei mit einer Pseudozufallsfolge am Stück von vorn bis > hinten beschreiben. > d) Die Testdatei am Stück auslesen und vergleichen. > e) Wiederhole c) und d) ad nauseam. Oder direkt auf das (raw) Block Device zugreifen. - Einmal alle Blöcke beschreiben. - Danach nur noch einen einzelnen Block schreiben (O_/SYNC, O_DIRECT oder per MMC), solange bis es zum I/O Fehler kommt. - Verschiedene Karten anhand der Aanzahl der Writes bis zum Auftritt des Fehlers vergleichen Wenn es darum geht die Karte schnellstmöglich zu zerstören: Während des Schreibzugriffs die Stromzufuhr kappen. Ein paar mal wiederholen. Lothar hat dazu ein paar Zahlen (wenn ich mich richtig erinnere). Edit: Wenn es unbedingt mit ext4 sein muss, halt eine Datei anlegen, und bspw. immer wieder den ersten Block schreiben (O_/SYNC, O_DIRECT). Vorher das Filesystem natürlich einmal voll machen.
:
Bearbeitet durch User
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.
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...
Alex G. schrieb: > Das große problem ist noch immer ob mand avona usgehen kann, ob > überhaupt Wear Leveling aktiv ist. Davon kannst du ausgehen, denn ohne FTL (Flash Translation Layer) ist aktueller, großer NAND praktisch unbrauchbar. In den µSD-Karten stecken 8051- oder ARM-Kerne dafür drin. usuru schrieb: > Im Armbian-Forum hat einer einen OrangePi (hat nur eine EXT4-Partion, > keine FAT-Partition) mehr als 150x hart ausgeschaltet und die SD-Karte > war immer noch nicht hinüber. Er muss dabei auch einen Schreibzugriff unterbrechen und selbst dann ist nicht jede Karte dafür anfällig. Und er wird auch sicherlich nicht alle Datenblöcke nach jedem Hardreset auslesen, also stehen die Chancen gut, dass er Datenkorruption nicht bemerkt. Es können irgendwelche Bereiche betroffen sein, unabhängig von TRIM. c-hater schrieb: > Warum auch? Damit kannst du höchstens die logische Struktur der Daten > beschädigen, aber nicht die Hardware. Die Firmware des Controllers ist auch in dem Flash gespeichert, nicht im Controller.
c-hater schrieb: > Warum auch? Damit kannst du höchstens die logische Struktur der Daten > beschädigen, aber nicht die Hardware. Jein, denn da fallen grade die Lebens-verlängernden Maßnahmen der Controler einem in den Rücken - fällt der Strom nämlich grade dann aus während irgendwas umkopiert oder umgeordnet wird, dann sind auch unbeteiligte Daten unter Umständen korumpiert und das können grade Daten sein welche das OS benötigt. Oder noch schlimmer, es ist die Firmware des Controlers selbst! Bei SSDs sind Fälle dokumentiert wo die SSD hinterher genau deswegen nicht mehr zugreifbar war. Als Nutzer kann man dazu schon sagen dass die Hardware "kaputt" ist. Darum haben inzwischen mehr SSDs, Stützkondensatoren. Denkbar wäre dass der Bananapi, auf dem Board mehr Stützkodnensatoren hat, als der Raspi. Selbst hab ich auch noch keine SD Karte dadurch gebrickt obwohl ich gut einige dutzend mal, den Strom abgeschaltet hab. Es ist aber ein Glücksspiel. S. R. schrieb: > Alex G. schrieb: >> Das große problem ist noch immer ob mand avona usgehen kann, ob >> überhaupt Wear Leveling aktiv ist. > > Davon kannst du ausgehen, denn ohne FTL (Flash Translation Layer) ist > aktueller, großer NAND praktisch unbrauchbar. In den µSD-Karten stecken > 8051- oder ARM-Kerne dafür drin. Ganze ARM kerne in einer Micro SD? Richtig faszinierend! Jedenfalls gut zu wissen.
:
Bearbeitet durch User
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.
Mikro 7. schrieb: > Hast du denn eine Quelle für deine gegenteilige Behauptung? Bei "besseren" Karten kann man SMART Daten auslesen. Und dort sieht man, dass bei einer Karte, die zu 95% mit statischen Dateienn belegt ist, trotzdem alle Flashblöcke verwendet werden. usuru schrieb: > m Armbian-Forum hat einer einen OrangePi (hat nur eine EXT4-Partion, > keine FAT-Partition) mehr als 150x hart ausgeschaltet Das läuft für mich immer noch unter "Zufall"... ? Bei meinem Dauerschreibtest werden gute SD Karten mindestens 15000 mal (also hundert mal mehr) ausgeschaltet. Die einzige Strategie, die zugrunde gelegt wird, ist, dass bei einem erkannten Powerfail kein neuer Schreibvorgang mehr gestartet wird und dass die Versorgung nach dem letzten Schreibbefehl noch mindestens 400ms gepuffert ist.
Ich denke das die Hersteller einen nicht komplett im Regen stehen lassen werden und schon ein paar Infos rausrücken. Bei Sandisk wird ja die höchste Garantie bei den Sandisk Extreme Pro gegeben, man kann ja mal anfragen was die Extreme Pro von einer Ultra oder High Endurance unterscheidet irgendetwas müssen Sie ja schreiben. Die High Endurance Karte ist ja für Videoaufzeichnungen gemacht, wo die Karte wieder und wieder überschrieben wird und hier werden alle Zellen gleichmäßig benutzt. Ein großartiges wearleveling wird hier nicht funktionieren, deswegen vermute ich sehr stark das hier qualitativ bessere SLC Speicherzellen zum Einsatz kommen, was die geringere Speicherkapazität erklären wurde. Für die meisten SLC-Flashspeicher geben die Hersteller 100.000 Zyklen an, für MLC sind es nur zwischen 1000 und 3000. Ich würde erstmal versuchen nur eine Zelle/Block wiederholt zu beschreiben, zur noch mit der kleinsten Kapazität damit der Test nicht so teuer ausfällt. Und danach eine möglichst große Karte des Siegermodels kaufen um den wear leveling hohe Chancen zu geben. Oder eben von USB-SSD Platte zu starten hier kann man sich bewusst für SLC und gegen MLC und TLC entscheiden.
Thomas O. schrieb: > Ich denke das die Hersteller einen nicht komplett im Regen stehen lassen > werden und schon ein paar Infos rausrücken. LOL Sach' mal, in dieser (unserer) Welt bist du noch nicht sehr lange, oder?
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.
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?
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.
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
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!
Ich wäre auch daran interessiert wie du Smart ausliest (MMC,SDIO); sowie bei welchen Karten das geklappt hat und bei welchen nicht.
Lothar M. schrieb: > Du hast überhaupt nicht die Wahl, von aussen eine definierte > Speicherzelle des Flashs anzusprechen. Auch wenn du ständig von aussen > den selben Block adressierst, wirst du immer wieder einen anderen > Flash-Block bearbeiten, weil der Controller die Zugriffe ummappt. Das denke ich aber schon,indem man nur einen Block frei läßt(rest vollmachen oder anderst partitionieren) und diesen immer wieder löscht/beschreibt. Ich denke nicht das die dann wirklich die Blöcke mit bereits verwendeten tauschen. Da würden die Schreibraten ja extremst einbrechen.
900ss D. schrieb: > Also ich korrigiere meine Aussage insoweit, dass in SD-Karten nicht > umkopiert wird. Um diesen Speicher geht es hier ja. Hier ein Hersteller, der es macht. Damit wäre zumindest die Behauptung widerlegt, dass es kein Wear Leveling auf SD Karten gibt. https://www.mouser.de/pdfdocs/S-45_fact_sheet1.pdf In der Praxis bleibt es aber ein Problem herauszufinden, ob/welche Art von Waer Leveling implementiert ist, wenn man keine Spec. hat. Da könnte dann Smart ggf. einen Hinweis liefern.
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.
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.
Auch Samsung und Sandisk haben seit dem white paper von 2003 ihre Algorithmen ein wenig weiterentwickelt. Da arbeiten nicht nur Arduino-Bastler.
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.
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:
1 | lspci |
2 | .. |
3 | 46:06.1 System peripheral: Ricoh Co Ltd R5C843 MMC Host Controller |
soul e. schrieb: > Auch Samsung und Sandisk haben seit dem white paper von 2003 ihre > Algorithmen ein wenig weiterentwickelt. Solange es kein Paper/Datenblatt gibt, wo beschrieben steht, dass sie static wear-leveling betreiben, ist für mich auch keins drin. Nicht umsonst sind die Swissbit-Karten auch deutlich teurer.
c-hater schrieb: > Das Problem sind die Seiten, in denen die internen > Verwaltungsinformationen der Firmware stehen, nicht die, in denen die > Firmware selbst steht. Einverstanden. Ob die Karte nun aber nicht mehr funktioniert, weil die Firmware beschädigt ist oder wegen beschädigter Metadaten beim Start abstürzt, kann mir als Nutzer relativ egal sein. Thomas O. schrieb: > [immer nur eine Zelle/Block beschreiben geht nicht] > Das denke ich aber schon,indem man nur einen Block frei läßt(rest > vollmachen oder anderst partitionieren) und diesen immer wieder > löscht/beschreibt. Du glaubst, dass in einer 8 GB großen SD-Karte auch 8 GB Flash verbaut und (minus der Controllerfirmware) für den Nutzer bereitgestellt sind. Dem ist nicht immer so. Bunnie (der sich ebenfalls mit SD-Karten beschäftigt hat) meinte mal in einem Vortrag, dass er in einer 128 MB großen SD-Karte sagenhafte 16 GB Flash gefunden hat. Der Rest war halt schon ab Werk defekt. Die Margen sind bei Flash so gering, dass jeder Baustein auch verwendet werden muss, egal welcher Qualität.
SDMI schrieb: > Hm, hier (HP notebool) ist es eine PCI-to-X bridge: Was hat das jetzt mit einem Raspberry Pi zu tun?
Karl schrieb: > Wie willst Du das denn definieren? Datenlogger, NAS, Spielepi... da > gibts doch die verschiedensten Muster. In der Tat schwierig. > Auch bei mySQL oder SQlite ist mir nicht klar: Wird da bei jedem Eintrag > neu geschrieben? Oder wird erst geschrieben, wenn eine bestimmte Menge > Daten zusammensind? Das ist bei SQLite so, dass IMMER sofort geschrieben wird, wenn Du nichts spezielles machst (implizite Transaktion). Das kann sehr zaeh werden, wenn Du jeden einzelnen Record schreibst (auch bzw. gerade bei Festplatten). Wenn Du 100 Schreibaufrufe in einer Transaktion buendelst, wird erst am Ende der Transaktion geschrieben. WIE geschrieben wird, haengt vom Modus ab. Ich empfehle bzw. verwende WAL (https://www.sqlite.org/wal.html), das schreibt erst mal in ein Log. Das duerfte generell guenstiger sein fuer die Karte, unabhaengig vom Filesystem und hat noch ein paar weitere Vorteile (siehe Link). > Am Kartenschonendsten finde ich hier die gute alte csv-Datei: Die Daten > werden einmal geschrieben und dann nicht wieder angefasst. Neue Daten > werden nur ans Ende angefügt und für den nächsten Tag / Monat... wird > eine neue Datei angelegt. Gewiss, ich bin sowieso ein Fan von Textdateien. Nur benoetigt man oftmals doch eine Datenbank, z.B. SQLite. > Oder halt Round-Robin in einer Ramdisk und regelmäßig die Daten > exportieren. Aber die exportierten Daten dann in Ruhe lassen. Dann hast Du aber ein Problem, wenn Du Stromausfaelle nicht ausschliessen kannst. Ich versuche mit der ganzen Aktion in der Praxis (!!) folgendes herauszufinden: 1) Welche Karten sind besser und welche schlechter? 2) Ist ext4 fuer Dauerbetrieb gut genug? 3) Ist f2fs besser und, vor allem, ext4 vorzuziehen?
Rufus Τ. F. schrieb: > Da die SD-Karte am Raspberry Pi nicht über USB angebunden ist (wie sonst > eigentlich alles), würde diese Massenspeicheranbindung keine > USB-Bandbreite verbrauchen. Leider ist die Rpi SD-Schnittstelle etwas lahm, soweit ich weiss auch beim Raspi3 nicht wesentlich ueber 20MB/s hinaus.
S. R. schrieb: > Bunnie (der sich ebenfalls mit SD-Karten beschäftigt hat) meinte mal in > einem Vortrag, dass er in einer 128 MB großen SD-Karte sagenhafte 16 GB > Flash gefunden hat. Der Rest war halt schon ab Werk defekt. Die Margen > sind bei Flash so gering, dass jeder Baustein auch verwendet werden > muss, egal welcher Qualität. Das ist ganz sicher so. Aber der zusaetzliche Speicher ist ja defekt und kann auch vom Controller nicht genutzt werden. Ausser bei China-Fake-Karten ;-)
B. R. schrieb: > 1) Welche Karten sind besser und welche schlechter? Der vermutlich einzige hier mit handfesten Daten ist Lothar und seine Erfahrungen findest du weiter oben sowie in anderen Threads zum Thema. Allerdings darf ein Hersteller den Controller und die Algorithmen jederzeit wechseln, und das sieht man den Karten im Laden auch nicht an. Vermutlich nichtmal im Großhandel. Wie du an der Diskussion auch erkennen kannst, gibt es keine "ultimativ guten Karten", sondern nur Stichproben, anekdotische Erfahrungswerte, Vermutungen und allgemeines Wissen über die Möglichkeiten der Hersteller. Wie die Karte für dich performt, hängt schlussendlich ausschließlich von deinem Anwendungsfall ab. > 2) Ist ext4 fuer Dauerbetrieb gut genug? Eine eMMC unterscheidet sich technisch nicht wesentlich von einer SD-Karte, also gehe ich schlicht mal davon aus, dass da auch die gleiche Technik drin steckt. In Android-Geräten wird fast durch die Bank weg ext4 verwendet und (wenn ich mich recht entsinne) ist das auch eine Empfehlung von Google. Du kannst also davon ausgehen, dass ext4 gut genug funktionieren wird. Es ist sehr gut getestet, äußerst stabil und sehr robust gegenüber Datenfehlern. > 3) Ist f2fs besser und, vor allem, ext4 vorzuziehen? Ich habe f2fs mal angetestet und habe keine schwerwiegenden Probleme festgestellt. Einige Android-Geräte nutzen das auf ihren internen eMMCs, also wird auch das funktionieren. Die Performance verglichen mit ext4 dürfte je nach Anwendungsfall bei "geringfügig mehr" bis "deutlich weniger" liegen, da ext4 meines Wissen nirgends komplett versagt. Auf einem Raspberry kann dir das aber ohnehin egal sein, weil die Schnittstelle ohnehin langsam ist. Andererseits ist f2fs m.W. weniger robust gegenüber Datenkorruption, d.h. wenn die SD-Karte was kaputt macht, dann hast du geringere Chancen, an die Daten noch ranzukommen. Im Zweifelsfall gibt dir der Mountversuch eine Kernel Panic. Das wäre für mich der wichtigere Punkt: SD-Karten sind in meiner Wahrnehmung schlicht unzuverlässig und ext4 kann da möglicherweise noch mehr retten als f2fs. Daher würde ich auf ext4 setzen, wenn es nicht gerade um Spielereien (oder den letzten Rest an Performance) geht. B. R. schrieb: > Aber der zusaetzliche Speicher ist ja defekt und kann auch vom > Controller nicht genutzt werden. Ausser bei China-Fake-Karten ;-) SD-Karten werden nur in Standardgrößen verkauft (ungefähre Zweierpotenzen). Wenn von dem verbauten Flash also nur 6 GB einigermaßen zuverlässig sind, würde ich davon ausgehen, dass die Karte als "4 GB" in den Handel kommt und 2 GB an Reservesektoren fürs Wear-Levelling enthält.
S. R. schrieb: > sondern nur Stichproben, anekdotische Erfahrungswerte, Deshalb habe ich erst mal meine eigenen Performancetests gemacht (Beitrag "Re: zuverlässige SD-Karte für Raspberry Pi") mit durchaus stark unterschiedlichen Ergebnissen zwischen einzelnen Typen. Momentan mache ich einen Zuverlaessigkeitstest mit einigen der Karten, die ich ausgehend von den Performancetests in die engere Wahl genommen habe. Jedenfalls ist richtig, dass die Aussagekraft solcher Tests zum einen nur auf exakt das gleiche Modell gilt (siehe z.B. die eklatanten Unterschiede oben zwischen einer "Samsung Evo+ 32GB" und dem "besseren" Nachfolger "Samsung Evo plus 32GB"). Zum anderen sollte man selbst bei exakt gleicher Type die Tests in gewissen Intervallen bei einer neuen Charge wiederholen, weil niemand garantiert, dass nicht doch etwas innerhalb der gleichen Type geaendert wird. Erschwerend kommt hinzu, dass solche moeglichen Aenderungen immer auf den urspruenglichen Anwendungszweck abzielen ("Fotoapparat") und vielleicht im Raspi massivere Auswirkungen haben. > Die Performance verglichen mit ext4 dürfte je nach Anwendungsfall bei > "geringfügig mehr" bis "deutlich weniger" liegen, da ext4 meines Wissen > nirgends komplett versagt. Auf einem Raspberry kann dir das aber ohnehin > egal sein, weil die Schnittstelle ohnehin langsam ist. Laut meinen Tests ist die Leseperformance fast identisch, die Schreibperformance gerade bei kleinen random Zugriffen (und genau diese sind beim Raspi massgeblich, noch staerker bei einer DB-Anwendung) um Faktoren hoeher (EurEx ist Preis exkl. MwSt, Datenraten in MByte/s):
1 | flashbench Raspi3 f2fs |Typ|Typennummer |EurEx|RSEQ|WSEQ|RRND|WRND |
2 | ------------------------+---+------------------+-----+----+----+----+---- |
3 | Sandisk Extreme 32GB V30|uSD|SDSQXAF-032G-GN6MA| 16.0|19.7|19.2| 9.0|19.0 |
4 | Transcend Ult. 600x 8GB |uSD|TS8GUSDHC10U1 | 6.5|21.5|13.1| 5.7|13.5 |
5 | Adata Premier 8GB |uSD|AUSDH8GUICL10 | 6.8|17.8| 7.5| 6.0| 8.7 |
6 | xlyne SDHC 8GB |uSD|7408001 | 5.4|14.3|10.9| 4.4| 8.0 |
7 | |
8 | flashbench Raspi3 ext4 |Typ|Typennummer |EurEx|RSEQ|WSEQ|RRND|WRND |
9 | ------------------------+---+------------------+-----+----+----+----+---- |
10 | Sandisk Extreme 32GB V30|uSD|SDSQXAF-032G-GN6MA| 16.0|21.9|20.6| 9.3| 6.8 |
11 | Transcend Ult. 600x 8GB |uSD|TS8GUSDHC10U1 | 6.5|21.5|14.5| 5.9| 1.4 |
12 | Adata Premier 16GB |uSD|AUSDH16GUICL10-R | 6.8|21.6| 9.8| 5.6| 1.5 |
13 | xlyne 8GB |uSD|7408001 | 5.4|19.5|11.5| 4.4| 1.4 |
Wenn Geld keine Rolle spielt bzw. man die maximale Performance bzw. Platz braucht, wuerde ich erst mal zur Sandisk Extreme 32GB V30 (SDSQXAF-032G-GN6MA) raten, sonst zur Transcend Ultimate 600x 8GB (TS8GUSDHC10U1). Jedenfalls werde ich das so machen. > Andererseits ist f2fs m.W. weniger robust gegenüber Datenkorruption, Das glaube ich eher nicht. Insbesondere geht das f2fs schonender mit dem FLASH um (das teste ich ja gerade). Siehe auch https://www.usenix.org/system/files/conference/fast15/fast15-paper-lee.pdf. Und das f2fs ist ganz speziell auf FLASH ausgelegt, was das ext4 definitiv nicht ist. Ich denke daher, dass das f2fs die bessere Alternative fuer die Anwendung "uSD im Raspi" ist und werde es selbst auch verwenden. Das werden erst mal ca. 50 Geraete sein sein mit einer SQLite bzw. MariaDB Anwendung drauf mit nicht unerheblichen Datenmengen. Gerne berichte ich in etwa einem Jahr hier, wie sich das f2fs geschlagen hat. > SD-Karten werden nur in Standardgrößen verkauft (ungefähre > Zweierpotenzen). Wenn von dem verbauten Flash also nur 6 GB einigermaßen > zuverlässig sind, würde ich davon ausgehen, dass die Karte als "4 GB" in > den Handel kommt und 2 GB an Reservesektoren fürs Wear-Levelling > enthält. So wird das wohl gemacht, ja.
Lothar M. schrieb: > Dieser Dauerschreibtest läuft nun mit unterschiedlichen Karten seit ca. > 3 Jahren und er wird auch die nächsten Jahre noch weiterlaufen. Ich weiss, schon etwas spaet, aber eventuell liest Du ja trotzdem: Moechtest Du nicht mitteilen, welche Karten Du im Test hast und wie der Algorithmus Deines Dauerschreibtests aussieht?
SDMI schrieb: > Dann mal bitte: Butter => Fische! Ich habe schon seit dem Beitrag "Re: zuverlässige SD-Karte für Raspberry Pi" und lange vorher Butter an die Fische getan. Ich will mich nicht wiederholen... ;-) B. R. schrieb: > Moechtest Du nicht mitteilen, welche Karten Du im Test hast ATP, Kingston, Samsung, SanDisk, Swissbit, Toshiba, Innodisk und die XMore (und noch einige der ganz billigen TLC-Consumer-Karten, aber die flogen alle schon nach kürzester Zeit, also ein paar Stunden oder wenigen Tagen aus dem Test). > und wie der Algorithmus Deines Dauerschreibtests aussieht? 1. Vorbereitung: Karte mit FAT32 formatiert und Karte zu 95% mit statischen Daten gefüllt 2. Ablauf - Einschalten und Start von dieser Karte - 300s lang laufendes Schreiben der selben Datei mit 50kByte Größe und sich ändernden Werten - Abschalten der Versorgung bei Erkennung des Powerfails wird kein neuer Schreibvorgang mehr gestartet, die Versorgungspannung liegt noch 500ms nach erkanntem Powerfail an - 15s Aus, dann von vorn 3. die Karte wird dann regelmäßig (derzeit 1x pro Woche, wenn beim Booten und Betrieb keine Auffälligkeiten zu sehen sind) entnommen, die statischen Daten manuell auf Veränderungen geprüft und die SMART-Daten protokolliert Die SMART-Daten einer XMore Karte, die seit Mai letzten Jahres im Test ist, sehen aktuell so aus:
1 | 1. Maker Information : pSLC |
2 | 2. WearSel Type : Embedded |
3 | 3. Endurance Life Ratio : 0.00% |
4 | 4. Good Block Ratio : 98.60% |
5 | 5. F/W ECC BIT Setting : 42 |
6 | 6. Total Refresh Count : 0 |
7 | 7. Total Power Up Count : 84633 |
8 | 8. Abnormal Power On Count : 0 |
9 | 9. Erase Count : Average : 37584 |
10 | Maximum : 37752 |
11 | Total Number : 37810363 |
12 | Erase Endurance : 20000 |
13 | 10. Maximum Block Replace Number : 48 |
14 | 11. Scan Bad Block : 30 |
15 | DIE : Early Bad : Later Bad |
16 | 0 : 30 : 0 |
Dort sieht man, dass ein besonderer "Embedded" Wearlevel-Algorithmus zugange ist (siehe meine früheren Beiträge). Die Restlebenszeit ist 0,00% (schon seit Mitte Oktober), weil jeder Block schon 37k mal gelöscht wurde, obwohl er nur für 20k spezifiziert ist. Und dass nach 85k Einschaltvorgängen zu den anfänglich defekten 30 defekten Blocks noch kein neuer dazugekommen ist.
:
Bearbeitet durch Moderator
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...
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.
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 :)
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?
MMC schrieb: > Antworten denn die XMore Karten auch auf: > mmc extcsd read /dev/mmcblk0 ? Das musst du selber ausprobieren. Den Befehl gibt es bei dem von mir verwendeten OS nicht ;-) 900ss D. schrieb: > von einem speziellen "embedded" Algorithmus habe ich noch nicht gehört. Ja, du hast den Trick erfasst: weil das Ganze sowieso herstellerspezifisch ist kann der seinen Werlevel-Algorithmus nennen wie er gerne will. Wie schon wiederholt gesagt: du bekommst normalerweise die Karte SDU008GXPS8C016 mit Z am Ende: https://www.glynshop.com/erp/owweb/Daten/Datenblaetter/DRAM_FLASH_MEDIEN/03_SD/02_Xmore/microSD/pSLC/15nm/Xmore%20professional%20SDUxxxxXPx8x016Z%20v2.5.pdf Auf Nachfragen und bei speziellen Problemen gibt es aber auch andere Wearlevel-Algorithmen. Und dann kommt z.B. ein E ans Ende...
:
Bearbeitet durch Moderator
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.
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
Ich habe mir zunaechst mal die "xlyne SDHC 8GB (740800)" und die "Transcend Ultimate 600x 8GB (TS8GUSDHC10U1)" vorgeknoepft und einen "Kaputtschreibtest" auf einem Raspberry Pi 3 durchgefuehrt. Die Aufteilung der SD-Karten war bei Nr. 1 und 2 (siehe unten) eine 5GB Datenpartition und eine 2.7GB leere Partition, jeweils mit dem entsprechenden Filesystem formatiert (das Raspbian war auf einem USB-Stick, von dem gebootet und von dem auch das Testprogramm gestartet wurde). Weil das meinem spaeteren Anwendungsfall eher entspricht, bin ich fuer Test Nr. 3 dazu uebergegangen, eine 3.7GB Raspbian-Partition mit dem Testprogramm drauf (ca. 70% gefuellt) und eine 3.7GB Datenpartition fuer die Schreibtestdatei zu erzeugen. Der Testalgorithmus laeuft wie folgt: A) Testdatei erzeugen/oeffnen mit O_SYNC|O_DIRECT (Posix open) B) Abwechselnd mit je 1MByte 0x55 und 0xAA beschreiben (offset 0, Posix write) C) Nach jedem schreiben wieder zuruecklesen/pruefen (Posix read) Mounten bei ext4 mit "noatime,nodiscard" und f2fs mit "noatime" (nodiscard gibts hier nicht).
1 | Nr | uSD | fs | TB | MB/s |
2 | ----+-----------------------------+----+----+----- |
3 | 1 | xlyne 8GB 7408001 |ext4| 1.3| 3.4 |
4 | 2 | xlyne 8GB 7408001 |f2fs| 1.3| 8.0 |
5 | 3 | Transcend 8GB TS8GUSDHC10U1 |f2fs| 5.5| 8.0 |
Spalte "TB" sind die Terabyte, die insgesamt geschrieben bzw. ueberschrieben wurden. Spalte "MB/s" ist die erzielte mittlere Datenrate in MByte pro Sekunde (schreiben inkl. zuruecklesen und pruefen). Die beiden uSD Karten zeigten soweit keinerlei Datenfehler oder andere "Abnuetzungserscheinungen" (z.B. sank die Datenrate gegen Ende NICHT, auch nicht beim ext4 Test). In den naechsten Monaten werde ich den Schreibtest so weit treiben, bis die uSD Karten kaputt sind. Angesichts der bisherigen Ergebnisse duerfte das aber noch einige Zeit in Anspruch nehmen. Zwischenzeitlich werde ich mir noch die Sandisk Extreme 32GB (SDSQXAF-032G-GN6MA) vornehmen.
Interessant! Denke weiter totschreiben bringt nichts, das ist ja schon weitab jeglicher realer Nutzung. Viel interessanter wäre da doch der Abschalt-Test!
> Denke weiter totschreiben bringt nichts, das ist ja schon weitab > jeglicher realer Nutzung. Es waere trotzdem interessant zu erfahren, wann die Teile WIRKLICH sterben. Dass die ueberhaupt solange gehalten haben (5TB mit der recht preiswerten Transcend bisher, das ist schon mal eine Ansage) fuehre ich grossteils auf das f2fs zurueck, weil das im Prinzip ja "perfektes" wear leveling betreibt. > Viel interessanter wäre da doch der Abschalt-Test! Das mache ich noch. Ich denke, folgende Vorgehensweise waere sinnvoll: 1) Schreiben mit dem gleichen Testprogramm wie oben (also eine 1MB Datei abwechselnd mit 0x55 und 0xAA beschreiben) 2) Versorgung kappen 3) Versorgung wieder dran und booten 4) Pruefen, ob der RPI3 ueberhaupt hochkommt, ob es irgendwelche Fehlermeldungen/Probleme gibt und wie die Testdatei aussieht. Vielleicht das ganze so 25-50x wiederholen. Mal sehen ob ich das irgendwie automatisieren kann, sonst wird das muehsam.
B. R. schrieb: > grossteils auf das f2fs zurueck Das hilft bei SD-Karten mit eigenem Wear-leveling überhaut nicht. f2fs hilft, wenn du mit den Blocknummern von diesem dann direkt auch diese Blöcke ansprechen kannst. Also quasi raw-NAND-Zugriff hast. Wenn aber ein SD-Karten wear-leveling dazwischen geschaltet ist, dann werden die Blocknummern verändert. Da kannst du dann soviel f2fs nehmen wie du möchtest.
Da bin ich ganz anderer Meinung. Das wear-leveling der uSD-Karte schlaegt nur dann zu, wenn sich durch das Schreibmuster ergibt, dass ein physikalischer (!!) Sektor mehrfach beschrieben wird. Alles andere waere wenig sinnvoll und/oder zuviel Aufwand bzw. traue ich sowas den uSD Controllern gar nicht zu. Selbst wenn diese Annahmen nicht zutreffen, ist es ein Vorteil, f2fs statt ext4 zu verwenden statt ext4, hauptsaechlich wegen der Log-Struktur (das zeigen bisher auch alle meine Testdaten). Und es ist generell keine gute Idee, sich auf irgendwelche uSD internen wear-leveling Algorithmen, so sie denn ueberhaupt vorhanden sind, zu verlassen, und zwar aus mindestens 2 Gruenden: 1) Man weiss nie, ob ueberhaupt welche implementiert sind und falls sie das sind, wie die Algorithmen aufgebaut sind. 2) uSD Karten sind auf i.d.R. auf FAT optimiert und auf den Einsatz in einem Fotoapparat oder aehnlichem, nicht auf Raspis mit ext4. Mir geht es bei dem Test nur darum, zu erfahren, wie gut ausgewaehlte uSD Karten mit f2fs massives (ueber-) schreiben wegestecken. Ob das nun auf die Karte, das FS oder auf beides zurueckzufuehren ist, ist mir egal.
:
Bearbeitet durch User
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.
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.
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
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.
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
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.
> 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.
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&px=SQLite-3.21-Released Ein kleiner Nachteil ist, dass etwas mehr vom FLASH fuer Verwaltungszwecke abgezwackt wird.
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.
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?
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.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.