Morgen zusammen.
Ich suche eine elegante Art, mein Speicherbereich (aus sicht der
Firmware) zu unterteilen. Die Daten werden ohne Dateisystem gespeichert
und das funktioniert bis jetzt ohne Probleme.
Die bisherige Unterteilung war recht simpel per defines realisiert.
Am Anfang ein wenig Platz für FW Daten und Update, danach reiner
Datenspeicher.
// Ab Page 32768 / Datenbereich, für Messungen etc.
15
#define MEM_DATA (MEM_SYS_MEM_SIZE)
16
17
#define ADDR_TO_PAGE(addr) (addr / 512)
Das funktioniert zwar, jedoch habe ich mich gefragt ob man das nicht
irgendwie anders machen kann...
Vielleicht mit const Struktur, die die Definitionen enthält?
Mir fällt gerade nichts elegantes ein.
Wichtige Infos wären:
- Beginn vom Speicherbereich
- Größe vom Speicherbereich
- Belegter / freier Speicherbereich
- ...?
Bin für jede Idee offen, auf Dateisysteme sollte jedoch verzichtet
werden.
Gruß
Adam P. schrieb:> Ich suche eine elegante Art, mein Speicherbereich (aus sicht der> Firmware) zu unterteilen. Die Daten werden ohne Dateisystem gespeichert
Warum? Das ist in den allermeisten Fällen nicht sinnvoll. Es gibt
mehrere, überaus stabile und leistungsfähige Dateisysteme, u.a. das
bekannte FATfs von ELM Chan.
http://elm-chan.org/fsw/ff/00index_e.html
Das kann ich überaus empfehlen. Damit ist der Dateizugriff spielend
leicht und leistungsfähig. Und die Daten sind auf jedem PC oder
sonstigen Gerät les- und schreibbar. Außerdem muss man sich nicht mit
dem Low Level Kram quälen.
>Bin für jede Idee offen, auf Dateisysteme sollte jedoch verzichtet>werden.
Warum? Denkst du, das wird besser, einfacher, schneller?
Wie willst du die Daten auf die SD-Karte bekommen? Mit einem HEX-Editor?
Spezialsoftware?
Falk B. schrieb:> Es gibt> mehrere, überaus stabile und leistungsfähige Dateisysteme, u.a. das> bekannte FATfs von ELM Chan.Falk B. schrieb:> Und die Daten sind auf jedem PC oder> sonstigen Gerät les- und schreibbar. Außerdem muss man sich nicht mit> dem Low Level Kram quälen.Falk B. schrieb:> Wie willst du die Daten auf die SD-Karte bekommen? Mit einem HEX-Editor?
Das schreiben der Messdaten ohne Dateisystem ist historisch bedingt.
Die SD Karte ist fix verbaut und soll gar nicht vom PC direkt
gelesen/beschrieben werden können.
Die Daten werden per USB ausgelesen und von einer Software
interpretiert.
Ich weiß leider nicht wie perfomant die FATfs vom ELM Chan ist.
Im moment fallen ca. 176Byte / ms an und werden per DMA weggeschrieben.
Der Umbau des Systems würde wohl nicht ganz so weinfach werden.
Bei SD Karten wurde das FAT Dateisystem zur Pflicht gemacht.
Dementsprechend garantieren deren Hersteller das Korrekte Funktionieren
des Wear Leveling nur mit FAT, welches wiederum einen erheblichen
Enfluss auf Performance und Lebensdauer der Karte hat. Ich habe noch
keine SD Karte gesehen, wo andere Dateisysteme (oder keins) ausdrücklich
zugelassen sind.
Achtung: Für SDXC Karten ist das Dateisystem exFat vorgeschrieben.
Adam P. schrieb:> Ich weiß leider nicht wie perfomant die FATfs vom ELM Chan ist.> Im moment fallen ca. 176Byte / ms an und werden per DMA weggeschrieben.
Hmm, das sind immerhin 176kB/s. Das ist für eine SD-Karte zwar absolut
Peanuts, aber man muss beachten, daß die sich beim Schreiben ab und an
einige HUNDERT Millisekunden Pause gönnt, ja nach Modell! Diese Zeit
mußt du mit einem FIFO puffern. Bei meinen Experimenten vor gefühlt
100 Jahren waren das um die 300ms, teilweise etwas mehr. Hast du
genügend RAM, um das zu puffern?
> Der Umbau des Systems würde wohl nicht ganz so weinfach werden.
Glaub ich nicht so recht, ist aber egal. Naja, deine Datenmengen sind
schon recht groß, das kann man zwar auch mit seriellem FLASH machen, der
hat definierte Scheibzugriffszeiten, aber bei 16MB und mehr wird das
größer und teurer als ne SD-Karte. Vielleicht kann man die Wartepausen
beim Schreiben genauer ausmessen und vielleicht sind die bei den eher
kleinen Datenmengen auf KONSTANTEN Sektoradressen auch kleiner. Wer
weiß.
Also das Speichern funktioniert super, dass ist ja auch nicht das
Problem.
Nach langem ausprobieren von 0815 Karten, verwenden wir nun die
Cactus 32GB
https://www.cactus-tech.com/products/commercial-grade/microsd/
Zusätzlich habe ich 3x 2048K Buffer die das Puffern übernehmen.
Dabei bin ich noch nie an einen Punkt gekommen, wo die Karte mal zu
lange gebraucht hätte (wie du bereits sagtest, einige Karten sind da
echt schlimm).
Mir ging es eher um eine Möglichkeit den Zugriff und den Code eleganter
zu strukturieren.
Adam P. schrieb:> Ich suche eine elegante Art, mein Speicherbereich (aus sicht der> Firmware) zu unterteilen. Die Daten werden ohne Dateisystem gespeichert> und das funktioniert bis jetzt ohne Probleme.>> Die bisherige Unterteilung war recht simpel per defines realisiert.> Am Anfang ein wenig Platz für FW Daten und Update, danach reiner> Datenspeicher.> // 2 MB / (0 - 4095) / PG Daten und sonstiges> #define MEM_PG_STUFF (0x00000000u)> #define MEM_PG_STUFF_SIZE (0x00200000u)> // 2 MB / (4096 - 8191) / Firmware Update> #define MEM_PG_FW (MEM_PG_STUFF + MEM_PG_STUFF_SIZE)> #define MEM_PG_FW_SIZE (0x00200000u)> /* ... */
Was Du dir da bastelst, ist ein rudimentäres Filesystem, halt mit der
Hand am Arm, irgendwie eine Art "das Rad neu erfinden" ...
Kann man mach, würde ich mir aber sehr gut überlegen.
Was, wenn es die SD-Karte nicht mehr tut, was anderes her muss? Was,
wenn Scheffe plötzlich die Karte auswerfbar haben will? Was, wenn die
Kartenhersteller auf ein FS beharren?
Wieso willst du den ganzen Low-Level-Kram über deine ganze Firmware
gleichmäßig verteilen? Lesbarer und wartungsfreundlicher wird es dadurch
nicht.
just my 2ct
Adam P. schrieb:> Mir ging es eher um eine Möglichkeit den Zugriff und den Code eleganter> zu strukturieren.
Du willst ein eigenes, einfaches Filesytem erstellen. Hmmm.
FAT arbeitet mit einfach verketteten Listen. Man kann sich auch diverse
schlanke Implementierungen der Speicherverwaltung in der libc anschauen,
da wird ja auch sowas ähnliches verwaltet. Und auch dort müssen Blöcke
gelöscht und fusioniert werden, wenn man seinen Speicher nicht endlos
fragmentieren will. Da bieten sich Arrays mit passenden structs an.
Kann man alles machen. Ob das sinnvoll ist, bleibt fraglich. Ich hätte
beim Thema wear leveling die größten Bedenken. Wie das genau läuft und
ob es schlau genug ist, ohne FAT die logischen Sektoren auf möglichst
viele physische Sektoren aufzuteilen, bleibt fraglich. Wieviele
Schreibzugriffe erfolgen denn voraussichtlich auf einen Datenblock
während der Lebensdauer deines Geräts?
Adam P. schrieb:> Mir ging es eher um eine Möglichkeit den Zugriff und den Code eleganter> zu strukturieren.
GPT-Partitionen existieren, und Du kannst Dir auch eigene
Partitionstypen definieren, wenn Du unbedingt musst. Damit würden fremde
Betriebssysteme wissen, dass die Karte benutzt wird.
fchk
Hannes schrieb:> Was Du dir da bastelst, ist ein rudimentäres Filesystem, halt mit der> Hand am Arm, irgendwie eine Art "das Rad neu erfinden" ...
Dieser Aufbau (Prinzip) ist schon seit locker >10 Jahren so.
Vorher war es MMC, dann NAND, nun SD.
Wie gesagt, historisch bedingt. Gewisse Logik steckt auch in der PC
Software.
Ich will es irgendwie anders machen, aber auch nicht alles über den
Haufen werfen... würde so auch nicht eben mal möglich sein.
Falk B. schrieb:> Und auch dort müssen Blöcke> gelöscht und fusioniert werden, wenn man seinen Speicher nicht endlos> fragmentieren will.
Der Datenbereich wird für jede neue Messung gelöscht.
Eine Fragmentierung findet nicht statt.
Falk B. schrieb:> Wieviele> Schreibzugriffe erfolgen denn voraussichtlich auf einen Datenblock> während der Lebensdauer deines Geräts?
1 Messung je Tag, Datenmenge von ca 80MB - 2GB (je nach Samplingrate).
Adam P. schrieb:> Der Datenbereich wird für jede neue Messung gelöscht.
Wenn du das ohne Wear Levelling machst, ist die Karte nach 20 Messungen
verschlissen.
Frank K. schrieb:> GPT-Partitionen existieren, und Du kannst Dir auch eigene> Partitionstypen definieren, wenn Du unbedingt musst.
Ja sowas in der Art als Definition in der FW.
Also das die Table fix ist und nicht irgendwo auf der SD Karte liegt.
Stefan ⛄ F. schrieb:> Wenn du das ohne Wear Levelling machst, ist die Karte nach 20 Messungen> verschlissen.
Dann frage ich mich jedoch, warum die Geräte mit SD Karte seit 3 Jahren
im Feld ohne Probleme funktionieren.
Aber ja, ich weiß was du meinst.
edit:
Meinst nicht das die Karte soviel Logik intern hat, dass sie das selbst
regelt?
Adam P. schrieb:> Meinst nicht das die Karte soviel Logik intern hat,> dass sie das selbst regelt?
Das ist ja gerade die Frage, die dir hier niemand beantworten kann.
Frage den oder die Hersteller.
Garantiert ist die ordnungsgemäße Funktion wie gesagt nur mit FAT
Dateisystem. Das steht sogar bei vielen Karten auf dem Beipackzettel,
meist in Form von "Do not re-format this card" oder ähnlich.
Stefan ⛄ F. schrieb:>> Der Datenbereich wird für jede neue Messung gelöscht.>> Wenn du das ohne Wear Levelling machst, ist die Karte nach 20 Messungen> verschlissen.
Häää? Wieso das denn? Die Flash-Zellen in diesen Speichern haben so um
die 10.000 Schreib/Lösch Zyklen.
Adam P. schrieb:> Der Datenbereich wird für jede neue Messung gelöscht.> Eine Fragmentierung findet nicht statt.>> Falk B. schrieb:>> Wieviele>> Schreibzugriffe erfolgen denn voraussichtlich auf einen Datenblock>> während der Lebensdauer deines Geräts?>> 1 Messung je Tag, Datenmenge von ca 80MB - 2GB (je nach Samplingrate).
Wozu brauchst du dann ein Dateisystem? Du hast doch nur 1 Datei. Oder
wird nur einmal pro Tag eine Messung gemacht und damit 1 Datei erstellt,
aber das über viele Tage, bevor der Speicher ausgelesen und gelöscht
wird? Aber auch dann ist es einfach. Anfangsadresse + Länge definieren
einen Datenblock eindeutig. Das als Array of structs, fertig.
Falk B. schrieb:> Wozu brauchst du dann ein Dateisystem? Du hast doch nur 1 Datei. Oder> wird nur einmal pro Tag eine Messung gemacht und damit 1 Datei erstellt,> aber das über viele Tage, bevor der Speicher ausgelesen und gelöscht> wird? Aber auch dann ist es einfach. Anfangsadresse + Länge definieren> einen Datenblock eindeutig. Das als Array of structs, fertig.
Genau darum geht es ja.
Im Moment sind es eine oder mehrere Messungen die hintereinander liegen.
Dafür braucht man kein Dateisystem.
Nun soll aber ein Datenbereich für andere Messdaten geschafen werden,
die gleichzeitig anfallen, aber nicht in den bestehenden "Stream"
eingeschleust werden können.
Das ist auch kein Hexenwerk, ich überlege lediglich ob es nicht etwas
besseres gibt als das mit defines aufzuteilen.
Das ist manchmal recht Fehleranfällig, wenn man in dem Bereich etwas
erweitert oder umschreibt.
Stefan ⛄ F. schrieb:> Garantiert ist die ordnungsgemäße Funktion wie gesagt nur mit FAT> Dateisystem. Das steht sogar bei vielen Karten auf dem Beipackzettel,> meist in Form von "Do not re-format this card" oder ähnlich.
Bei unserer stand nichts dergleichen, aber die Anfrage ist rauß.
Bin gespannt was ich an Infos zurückbekomme.
@Stefan Hast du eigentlich ahnung von was du da redest?
ich glaube nicht.
Eine SD Carte ist ein konstrukt aus einem SD-Flash Controller und einen
NAND Flash baustein.
Warlaveling, ... und den ganzen kruscht macht der SD-Flash Controller.
Schlussfolgerung, egal wie du mit der SD - Karte arbeitest, das
warleveling läuft immer mit. da das in der karte gemacht wird. ob nun
mit oder ohne Dateisystem.
Zum Thema FAT. Ja SD Karten sollten mit FAT formatiert werden, (Damit
sie auch in der digi cam funktionieren) ... nur es hindert dich keiner
drann das nicht zu tun. Die kanst du sogar partitionieren wenn du
möchtest, ... Ist halt nur die frage wie weit Windows damit kommt,
(Windows zeigt nur die erste Partiton an ) ... unter linux funktioniert
das alles super, sogar mit ext3, ...
Und ein RAW NAND hält je nach technologie zwischen 100.000 und 1.000
löschzyklen aus, ... ein mal täglich löschen, sind selbst im
schlechtesten fall 3 Jahre dauerbetrieb drin bevor die zelle den geist
aufgibt.
123 schrieb:> Warlaveling, ... und den ganzen kruscht macht der SD-Flash Controller.> Schlussfolgerung, egal wie du mit der SD - Karte arbeitest, das> warleveling läuft immer mit. da das in der karte gemacht wird. ob nun> mit oder ohne Dateisystem.
Kannst du diese Aussage beweisen?
Stefan ⛄ F. schrieb:> Garantiert ist die ordnungsgemäße Funktion wie gesagt nur mit FAT> Dateisystem.
Ich glaube nicht, dass die SD-Karten irgendeine Intelligenz bzgl.
verwendeter Dateisysteme haben. Letzlich wird auch ein FAT-Filesysterm
mit Block-Schreibbefehlen gefüttert und auch wieder blockweise gelesen.
Ich bin mir sicher, dass die Firmware da nichts reininterpretiert -
warum auch? Das Wear Levelling einer SD-Karte wird auch garantiert nicht
durch Verwendung eines uralten Dateisystems gefördert. Im Gegenteil:
Wenn die Hersteller das Wear Leveling optimieren wollten, hätten sie
schon längst ein Dateisystem gefordert/entwickelt, was der Verwendung
von SD-Karten entgegenkommt.
SD-Karten funktionieren auch perfekt mit anderen Dateisystemen wie
ext2,3,4. Ich habe da noch keine Nachteile feststellen können.
Mit der Aussage, dass FAT bzw. exFAT verwendet werden muss, wollen sich
die Hersteller meiner Meinung nur absichern, dass ihre Karte
größtmögliche Kompatibilität aufweist. Man steckst sie einfach in zig
Geräte und überall funktionieren sie. Deshalb verwendet man hier den
kleinsten gemeinsamen Nenner, welche die Geräte unterstützen. Und das
ist halt das uralte FATFS. Das ist meiner Meinung nach die einzige
Motivation für so eine Aussage.
Zum Thema:
Der TO will die SD-Karte lediglich in zwei Teile teilen und fragt, wie
man das anders als über #defines organisieren kann. Jetzt dafür ein
Dateisystem einzuführen ist wie mit Kanonen auf Spatzen schießen.
@TO: Schreibe einfach in den ersten Block der Karte einen Header, wo die
Größenverhältnisse drinstehen. Die kannst Du dann beim Einlegen der
Karte wieder auslesen und bist dann über die Größenverhältnisse
informiert.
Frank M. schrieb:> Ich glaube nicht, dass die SD-Karten irgendeine Intelligenz bzgl.> verwendeter Dateisysteme haben.
Wie kann sie dann wissen, welcher Block belegt und welcher frei ist?
Ohne das Dateisystem zu kennen kann die Karte keinen einzigen Block
verschieben oder tauschen. Es sei denn, sie verwendet dazu eine Mapping
Tabelle. Davon habe ich aber noch nicht gehört.
Dass die Karten nur mit FAT sicher ordnungsgemäß funktionieren, ist aber
allgemeiner Konsens - leider offenbar ohne jegliche Beweise. Es bleibt
wohl für immer das Geheimnis der Hersteller.
Stefan ⛄ F. schrieb:> Frank M. schrieb:>> Ich glaube nicht, dass die SD-Karten irgendeine Intelligenz bzgl.>> verwendeter Dateisysteme haben.>> Wie kann sie dann wissen, welcher Block belegt und welcher frei ist?
Da wird ein Verwaltungssystem im Hintergrund mitlaufen, im einfachsten
Fall ein Bit/Sektor, für gelöscht/beschrieben.
> Ohne das Dateisystem zu kennen kann die Karte keinen einzigen Block> verschieben oder tauschen. Es sei denn, sie verwendet dazu eine Mapping> Tabelle.
Eben.
> Davon habe ich aber noch nicht gehört.
Das ist mal sicher kein Argument ;-)
Stefan ⛄ F. schrieb:> Stimmt, es ist ein sehr schwaches. Ich finde ätzend, dass kein> Hersteller Infos dazu Preis gibt.
Ich nicht. Die SD-Karten werden zu 99% mit FAT betrieben und gut.
Außerdem steckt da ne Menge Betriebsgeheimnis dahinter.
Aber es ist tatsächlich so, daß jede SDCard munter auch mit allem
anderen als FAT funktioniert.
Ich nehme die auch regelmäßig mit ext... und anderen ohne Probleme.
Zumal FAT ja auch nicht gleich FAT ist. Da gibt es schon etliche
Varianten, und der Controller auf der Karte sieht nur daß Blöcke gelesen
und geschrieben werden. Daraus auf ein Dateisystem zurückzuschließen
wäre vollkommen sinnlos.
Das einzige, was der Controller höchstens mit FAT zu tun hat, ist daß
ein paar Parameter in den Algorithmen zum wear leveling der üblichen
Nutzung mit FAT entgegenkommen, und ein Hersteller ansonsten einfach
keine Aussagen zu etwas machen will, was nicht Mainstream ist.
Klaus W. schrieb:> Aber es ist tatsächlich so, daß jede SDCard munter auch mit allem> anderen als FAT funktioniert.> Ich nehme die auch regelmäßig mit ext... und anderen ohne Probleme.> Zumal FAT ja auch nicht gleich FAT ist. Da gibt es schon etliche> Varianten, und der Controller auf der Karte sieht nur daß Blöcke gelesen> und geschrieben werden. Daraus auf ein Dateisystem zurückzuschließen> wäre vollkommen sinnlos.
Nicht ganz. Die FAT im FAT ;-) wird deutlich öfter geschrieben als die
normalen Datenblöcke, das muss der Controller abfangen, damit diese
Schreibzugriffe nicht zur Schwachstelle werden. Ich würde vermuten, daß
da schon ne Menge an Intelligenz und "Wahrsagen" in den Controllern
steckt, um das Filesystem zu "erraten" und entsprechend zu handeln. Z.B.
kann man mit einen Zugriffsstatistik sowas rausfinden. Oder einfach die
Daten im MBR lesen ;-)
Falk B. schrieb:> Die FAT im FAT ;-) wird deutlich öfter geschrieben
ja, klar.
Aber dazu schont/ersetzt der Controller nicht die Blöcke, auf denen er
die FAT vermutet, sondern er zählt intern die Zugriffe (egal in welchem
Bereich) und arbeitet mit diesen Zahlen.
Wenn man eine FAT hat, dann wird er dort entsprechend tauschen - anhand
der gezählten Zugriffe.
Jeder Controller für SDCard und eMMC hat (herstellerspezifisch
natürlich) diverse Funktionen, um sich solche Statistiken ausgeben zu
lassen.
Stefan ⛄ F. schrieb:> Ohne das Dateisystem zu kennen kann die Karte keinen einzigen Block> verschieben oder tauschen.
Doch. Die Karte wird zusätzlich zur Mapping-Tabelle eine Statistik
mitführen, wie oft ein Block beschrieben wurde - fertig. Dafür braucht
man kein Filesystem.
Ja, die Hersteller rücken dazu nichts raus. Aber Wikipedia erklärt
Wear-Leveling auch gänzlich ohne FAT:
https://en.wikipedia.org/wiki/Wear_leveling
Frank M. schrieb:> Ich glaube nicht, dass die SD-Karten irgendeine Intelligenz bzgl.> verwendeter Dateisysteme haben.
Naja, Intelligenz kann man das sicher nicht nennen, aber Tatsache ist,
dass sehr viele SD-Karten produziert werden, die wear leveling nur
für den Bereich betreiben, in dem sie das RootDir und die FAT vermuten.
Damit's nicht zu kompliziert wird und sich binär leicht aufdröseln läßt,
ist es schlicht der Anfang der Karte mit einer auf die nächste
Zweierpotenz aufgerundeten Größe von (Flash-)Sektoren.
Dass das so ist, läßt sich sehr leicht durch das (Nicht-)Auftreten des
bekannten "Schluckaufs" nachweisen. So lange man bei solchen Karten nur
auf den oberen Adressen rumschreibt, tritt der nämlich schlicht NICHT
auf. Ganz anders, wenn man intensiv im Bereich der FAT schreibt. Dann
tritt er auf. Sogar relativ häufig.
Damit ist zumindest sicher nachgewiesen, dass nur Schreibvorgänge auf
den ersten (vergleichsweise sehr kleinen Teil) der Karte das
wear-leveling triggern. Was das dann allerdings im Detail macht, kann
man so nicht ermitteln.
Ich würde mal vermuten, dass bei diesen Karten einfach ein Flashblock
vom Ende der Karte mit einem aus dem "FAT-Bereich" ausgetauscht wird.
Und dass die Größe dieses Blocks sehr deutlich über einem "nativen"
Flashsektor liegt.
So würde ich es jedenfalls machen, wenn ich Kosten optimieren und
deswegen Spare und Verwaltungs-Storage sparen müsste...
c-hater schrieb:> Frank M. schrieb:>>> Ich glaube nicht, dass die SD-Karten irgendeine Intelligenz bzgl.>> verwendeter Dateisysteme haben.>> Naja, Intelligenz kann man das sicher nicht nennen, aber Tatsache ist,> dass sehr viele SD-Karten produziert werden, die wear leveling nur> für den Bereich betreiben, in dem sie das RootDir und die FAT vermuten.
Was für ein Stuss.
> Dass das so ist, läßt sich sehr leicht durch das (Nicht-)Auftreten des> bekannten "Schluckaufs" nachweisen. So lange man bei solchen Karten nur> auf den oberen Adressen rumschreibt, tritt der nämlich schlicht NICHT> auf. Ganz anders, wenn man intensiv im Bereich der FAT schreibt. Dann> tritt er auf. Sogar relativ häufig.>> Damit ist zumindest sicher nachgewiesen, dass nur Schreibvorgänge auf
Aua.
Stefan ⛄ F. schrieb:> Bei SD Karten wurde das FAT Dateisystem zur Pflicht gemacht.
Jepp. Und Partitionen sind auch nicht erlaubt.
Benutzen sie die Spraydose ganau nach Anleitung! Sonst werden Sie
verhaftet!
Beim RaspberryPi wird beides nicht eingehalten.
Für mich ist's ein Blockdevice. Wie eine Festplatte oder ein USB-Stick.
Das die FW in der Karte schon das Dateisystem verfolgt, um heraus zu
bekommen, welche Speicherbereiche belegt und welche frei sind, ist
eigentlich zwingend. Dennoch sind die Medien gut genug um mehr als die
genannten 20 Schreibvorgänge auch mit anderen FS oder gar ohne,
durchzuhalten. Viel mehr!
Und welche Dateisysteme wirklich von Herstellern unterstützt werden ist
ja auch nicht bekannt.
Gruß
Jobst
Jobst M. schrieb:> Beim RaspberryPi wird beides nicht eingehalten.
Wohl auch deswegen ist er der Liebling der SD-Karten-Hersteller. Nix
kurbelt den Markt so sehr an, wie die von Pi's kaputtgeschriebenen
SD-Karten...
Jobst M. schrieb:> Beim RaspberryPi wird beides nicht eingehalten.
Ja. Und jetzt rate mal, wo die Leute ganz besonders oft über frühzeitig
verschlissene SD Karten berichten. Oder warum die Raspberry Pi
Foundation extra ausgewählte Karten für ihre Boards anbietet.
In der normalen Bevölkerung ist so gut wie niemandem klar, dass SD
Karten nicht ewig halten. Aber die Raspberry Pi Besitzer wissen es fast
alle. Ist das nicht auffällig?
c-hater schrieb:> Wohl auch deswegen ist er der Liebling der SD-Karten-Hersteller. Nix> kurbelt den Markt so sehr an, wie die von Pi's kaputtgeschriebenen> SD-Karten...
Ja, das war mal so. In letzter Zeit hatte ich aber keine mehr.
Entweder wird der Speicher immer besser oder das Wear Levelling ist
mittlerweile auch bei ext angekommen.
Oder es liegt einfach an der Größe, da nun mehr Blöcke alternativ zur
Verfügung stehen.
Die fehlende gewollte Partitionierungsmöglichkeit unterstützt die FAT
Theorie. Denn so befindet sich die FAT immer in einem Bereich.
Gruß
Jobst
Stefan ⛄ F. schrieb:> In der normalen Bevölkerung ist so gut wie niemandem klar, dass SD> Karten nicht ewig halten.
Wer das glaubt, ist naiv. Unabhängig vom Raspi.
Auch Festplatten (Achtung: kein Wear Levelling! ;) gehen kaputt.
Scheinen aber auch viele zu ignorieren, dass das so ist.
Gruß
Jobst
Jobst M. schrieb:> Wer das glaubt, ist naiv.
Und unerfahren. Nur wenige Menschen hatten kaputte SD Karten in der
Hand.
Außer halt bei den Raspberry Pi Besitzern, da ist der Anteil ungleich
höher. Das kann am Dateisystem liegen, oder auch an stärkerer Nutzung.
Wahrscheinlich ist die Kombination aus beidem relevant.
Immerhin gibt es lange Listen mit SD Karten die im Raspberry Pi gut oder
schlecht arbeiten. Bei vielen einigen steht sogar der Vermerk, dass sie
nur mit FAT32 funktionieren.
Dies ist eine dieser Listen: https://elinux.org/RPi_SD_cards
Adam P. schrieb:> Das funktioniert zwar, jedoch habe ich mich gefragt ob man das nicht> irgendwie anders machen kann...
Du könntest vorne Deine Daten für FW und Update wie gehabt speichern,
aber die reinen Daten von hinten beginnend nach vorne schreiben.
Die Grenzen "Anfang" und "Ende" sind Dir sowieso vorgegeben.
Wenn sich beide Bereiche treffen, dann hast Du die nächste Grenze
erreicht: Kein Platz mehr.
Ich habe Speicherkarten, die mittlerweile einige hundert Male komplett
neu beschrieben wurden und immernoch laufen. Die ganze Wear
Leveling-Geschichte ist bei Medien die einmal komplett nur in eine
Richtung beschrieben werden sowieso hinfällig.
Gruß
Jobst
Jobst M. schrieb:> Ja, das war mal so. In letzter Zeit hatte ich aber keine mehr.
Dann bist du vermutlich schlicht etwas klüger geworden und kaufst nicht
mehr den Billig-Schrott.
> Entweder wird der Speicher immer besser oder das Wear Levelling ist> mittlerweile auch bei ext angekommen.
Nein, nicht "mittlerweile". Es gab schon immer auch SD-Karten, die das
richtig gemacht haben. Nur waren die halt auch schon immer etwas
teuerer. Wobei "etwas" auch gern mal "deutlich" bedeuten konnte...
> Die fehlende gewollte Partitionierungsmöglichkeit unterstützt die FAT> Theorie. Denn so befindet sich die FAT immer in einem Bereich.
Ganz genau so ist das. Und deswegen wird dies natürlich im
Billich-Sektor auch gnadenlos ausgenutzt.
Das Schöne an diesem Schluckauf-Test ist: er ist sehr einfach zu
implementieren und zeigt das Elend schon lange, bevor die Karte
tatsächlich kaputt geht. Ich habe mir übrigens nicht mal die Mühe
gemacht, tatsächlich ein Programm dafür zu schreiben, ich mißbrauche
ddrescue im Kontext eines kleinen Batchs für diesen Zweck, das bietet
alle nötigen Features für diesen einfachen Test.
Wenn man also rauskriegt, dass so eine Karte zur Kategorie der
Scheiß-Karten gehört, formatiert man sie einfach wieder auf den
ursprünglichen Standard und gibt sie zurück oder benutzt sie "normal".
Wichtiger ist: Man kauft nie wieder von dieser "Marke" (in
Anführungszeichen weil: oft gefälscht) oder dem Anbieter.
Jobst M. schrieb:> Entweder wird der Speicher immer besser oder das Wear Levelling ist> mittlerweile auch bei ext angekommen.
Wear Levelling ist bei "Markenherstellern" gefühlt ne Ewigkeit Sandard.
Ich zitiere mich mal selbst aus
Beitrag "Re: SD Karte shutdown" Ist gerade mal 2
Monate her, daß ich das schrieb:
>Ernstzunehmende Hersteller haben das Feature schon seit gefühlt einer>Ewigkeit. Datenblätter für SD-Karten sind ja eher selten, daher aus>einem allgemeinen Dokument von Sandisk aus 2010!: "Wear leveling is an>intrinsic part of the erase pooling functionality of cards in the>SanDisk microSD Card Product Family using NAND memory."Stefan ⛄ F. schrieb:> Außer halt bei den Raspberry Pi Besitzern, da ist der Anteil ungleich> höher. Das kann am Dateisystem liegen, oder auch an stärkerer Nutzung.> Wahrscheinlich ist die Kombination aus beidem relevant.
Das liegt regelmäßig daran, daß die falschen Karten oder zu kleine
Karten oder Karten aus fragwürdiger Quelle bzw. fragwürdiger "Brand"
usw. usf. in Verbindung mit intensiver Nutzung der Karten verwendet
werden. Mit anderen Worten: Man spart am falschen Ende.
Frank M. schrieb:> Doch. Die Karte wird zusätzlich zur Mapping-Tabelle eine Statistik> mitführen, wie oft ein Block beschrieben wurde - fertig. Dafür braucht> man kein Filesystem.>> Ja, die Hersteller rücken dazu nichts raus. Aber Wikipedia erklärt> Wear-Leveling auch gänzlich ohne FAT:
Doch, natürlich "rücken" die Hersteller zum Thema was raus. Man müßte
die Info halt mal lesen. Alle Hersteller von SD-Karten außerhalb des
Consumer-Bereiches geben in ihren Datenblättern (die es sehr wohl gibt)
die TBW bzw. in Stunden Daueraufnahme für Videos an:
Exemplarisch mal für eine "WD Purple SC QD101" mit 64GB bis zu 32TBW.
Das geht ohne entsprechendes Wear-Levelling überhaupt nicht. Und so ne
Karte kostet im WD-Onlineshop, also einer hoffentlich hinreichend
sicheren Quelle um keine gefälschten Karten zu bekommen, gerade mal 15€.
Ähnlich sieht's für SanDisk High Endurance, SanDisk Max Endurance,
Samsung Pro Endurance usw. aus.
Auch wenn es ein wenig in Richtung FAT Diskussion ausgeartet ist ;)
danke euch allen für die Vorschläge.
Frank M. schrieb:> @TO: Schreibe einfach in den ersten Block der Karte einen Header, wo die> Größenverhältnisse drinstehen. Die kannst Du dann beim Einlegen der> Karte wieder auslesen und bist dann über die Größenverhältnisse> informiert.
Das habe ich auch schon überlegt.
Das wäre die Entscheidung, ob ich die Struktur (Aufteilung) fix in die
FW schreibe oder ob ich es auf die SD auslager.
Dies würde jedoch wieder die Gefahr mit sich bringt, dass wenn die erste
Page mal weg ist, alle Infos fehlen.
Da sich der Aufbau eigentlich nicht ändert, würde es für die FW Version
sprechen.
Jobst M. schrieb:> Du könntest vorne Deine Daten für FW und Update wie gehabt speichern,> aber die reinen Daten von hinten beginnend nach vorne schreiben.> Die Grenzen "Anfang" und "Ende" sind Dir sowieso vorgegeben.
Den Ansatz hatte ich auch schon im Kopf, jedoch so, dass sich der
Datenbereich 1 von unten nach oben bewegt und der Datenbereich 2 von
oben nach unten.
Warum? Mir ist zwar bekannt, dass der Datenbereich 2 langsamer und mit
weniger Daten befüllt wird, aber eine richtige Aussage treffen in
welchem % Verhätnis man diese aufteilen sollte ist nicht so leicht.
Ich werde die Ideen mal mit aufnehmen und noch ein wenig weiter grübeln.
Danke.
Adam P. schrieb:> Da sich der Aufbau eigentlich nicht ändert, würde es für die FW Version> sprechen.
Wenn er sich nicht ändert, lass ihn wie es ist. Es spricht dann nichts
gegen ein #define. Der Thread ist dann allerdings auch nutzlos.
Thread beobachten
Seitenaufteilung abschalten
