Guten Morgen zusammen, ich möchte Logs auf einer microSD ablegen. Dafür wollte ich einen Speicherbereich von 100 MB reservieren. Jetzt stehe ich vor dem Problem, dass ich bei jedem Boot die Stelle finden muss, ab der weitere Logs geschrieben werden können. Würde ich sequentiel durchlaufen, so bräuchte ich im schlimmsten Fall bei einer Leserate von 3-5MB/Sek. ca 20-30 Sekunden, dies ist nicht machbar. (Die Stelle finden, wo ein NULL-Eintrag ist - Ende/Beginn vom "Ringspeicher" bei vollem Speicher) Wenn ich mir nun eine "Header-Page" anlege, in der ich mir immer die zuletzt aktive Page merke, so würde ich diese "zu oft" beschreiben. Gibt es dafür irgendwelche Ansätze? Ich hatte mal etwas gesehen, da hatte einer mehrere Varianten mit einem EEPROM beschrieben, finde es leider nicht mehr. Gruß Adam
:
Bearbeitet durch User
Hol dir doch ein FRAM oder EEPROM und nutz den als Pufferspeicher. Wenn der voll is, schreibste den ganzen Kram auf die SD-Karte. Auf dem EEPROM/FRAM kannst du ja dann auch die letze Stelle speichern. Ich würde aber noch eine Prüfsumme,zufällig erstellte Nummer oder Datum hinterlegen um feststellen zu können wann die SD-Karte ausgetauscht wurde oder so.
Eine Art umgekehrt verkettete Liste? Im ersten Sektor hinterlegen, wo das Ende des ersten Log ist. Dort ist entweder direkt Schluss (NULL), oder es steht da das Ende des nächsten Logs. So kann man sich dann bis zum Ende der Logdaten hangeln. Dann ist man schneller, als wenn alles durchsucht werden muss, und die Sektoren müssen alle nur einmal beschrieben werden.
:
Bearbeitet durch User
Adam P. schrieb: > Wenn ich mir nun eine "Header-Page" anlege, in der ich mir immer die > zuletzt aktive Page merke, so würde ich diese "zu oft" beschreiben. Das stört bei einer SD-Karte nicht, da die ihr eigenes Wear-Leveling implementiert. Laut Spezifikation nutzt man FAT, und die FAT selbst liegt in den ersten Sektoren und wird ständig überschrieben.
Du könntest zwei Methoden kombinieren: Irgendwo speicherst du, wie groß das log ist. Aktualisierst diese Angabe aber nur z.B. alle 100kB. Beim Neustart springst du zu der gespeicherten Position und suchst von da an das wirkliche Ende. Abgesehen davon enthalten SD Karten einen Controller, die die Schreibzugriffe einigermaßen gleichmäßig verteilt. Bei den üblichen Filesystemen würde sonst das Inhaltsverzeichnis nicht funktionieren, denn das wird bei jedem Schreibzugriff mindestens 2x geändert und die meisten Rechner verzeichnen dort auch das Datum des letzten Lesezugriffs für jede einzelne Datei.
S. R. schrieb: > Adam P. schrieb: >> Wenn ich mir nun eine "Header-Page" anlege, in der ich mir immer die >> zuletzt aktive Page merke, so würde ich diese "zu oft" beschreiben. > > Das stört bei einer SD-Karte nicht, da die ihr eigenes Wear-Leveling > implementiert. Laut Spezifikation nutzt man FAT, und die FAT selbst > liegt in den ersten Sektoren ... der Partition. Es gibt ja eine Standard-Partionierung und -Formatierung für SD-Karten, die wohl auch sehr empfohlen wird. Das Wear-Leveling wird genau auf dieses Format ausgelegt. Nimmt man jetzt versehentlich einen Sektor, der normalerweise vor der ersten Partition liegt, ist dann möglicherweise die Karte besonders schnell kaputt, weil eigentlich davon ausgegangen wird, dass da eh praktisch nie einer was hinschreibt.
Schmackes schrieb: > Hol dir doch ein FRAM oder EEPROM und nutz den als Pufferspeicher. Hardware ist bereits fertig, sollte schon eine SW-Lösung sein. Rolf M. schrieb: > So kann man sich dann bis zum Ende der Logdaten hangeln Dies würde ja dann einer sequentielen Suche ähneln. S. R. schrieb: > Laut Spezifikation nutzt man FAT, und die FAT selbst > liegt in den ersten Sektoren und wird ständig überschrieben. So habe ich das noch gar nicht gesehen, aber stimmt auch wieder... Ich nutze kein FAT, lediglich RAW-Data. Stefanus F. schrieb: > Irgendwo speicherst du, wie groß das log ist. Aktualisierst diese Angabe > aber nur z.B. alle 100kB. > > Beim Neustart springst du zu der gespeicherten Position und suchst von > da an das wirkliche Ende. Wäre eine Idee, aber da es ja beim FAT auch immer Zugriffe gibt, sollte es vllt. wirklich kein Problem darstellen.
Rolf M. schrieb: > Nimmt man jetzt > versehentlich einen Sektor, der normalerweise vor der ersten Partition > liegt, ist dann möglicherweise die Karte besonders schnell kaputt, weil > eigentlich davon ausgegangen wird, dass da eh praktisch nie einer was > hinschreibt. Mhh... ok, dann hab ich mit meinem RAW-Data-System wohl schlechte Karten, wenn die SD-Karten das Wear-Leveling nur bei FAT erkennen und durchführen.
Binäre Suche; im wirklichen Leben erst binär und dann sequentiell sobald die Entfernung/Blockgröße kleiner als 4 bis 64kB wird (soviel, wie das Betriebssystem mindestens liest). Unabhängig davon ist Schmackes Zwischenspeicher empfehlenswert um möglichst große Blöcke am Stück auf die Karte zu schreiben.
:
Bearbeitet durch User
Adam P. schrieb: > Rolf M. schrieb: >> So kann man sich dann bis zum Ende der Logdaten hangeln > > Dies würde ja dann einer sequentielen Suche ähneln. Kommt drauf an, wie lang ein einzelnes Log ist. Wenn das immer auf einen Sektor passt, gewinnt man natürlich nichts. Es setzt voraus, dass es eher wenige große Logs gibt, damit man was gewinnt. Adam P. schrieb: > Rolf M. schrieb: >> Nimmt man jetzt >> versehentlich einen Sektor, der normalerweise vor der ersten Partition >> liegt, ist dann möglicherweise die Karte besonders schnell kaputt, weil >> eigentlich davon ausgegangen wird, dass da eh praktisch nie einer was >> hinschreibt. > > Mhh... ok, dann hab ich mit meinem RAW-Data-System wohl schlechte > Karten, wenn die SD-Karten das Wear-Leveling nur bei FAT erkennen und > durchführen. Zumindest muss man damit rechnen. Was der Controller tatsächlich intern macht, weiß man natürlich nicht. Aber immerhin ist in der SD-Spezifikation explizit erwähnt, dass sich die Controller auf eine ganz bestimmte Formatierung und Partitionierung verlassen dürfen. Und da FAT an sich eigentlich denkbar ungeeignet für Flash-Medien ist, liegt die Vermutung nahe, dass die Controller das auch tun.
Ich hab mal ein wenig gegrübelt. Um die letzte Page in meinem Datenbereich zu finden, verwende ich bereits die binäre Suche (Ist das erste Byte der Page 0x00 dann links weiter suchen, sonst rechts, da jede Page ein Signum-Byte enthält, falls beschrieben). Wenn ich nun meine Pages im Log-Speicher jeweils mit einem Tick signiere (jeden Log signieren wäre ein wenig zuviel des guten) - so könnte ich dieses Verfahren etwas abgewandelt ebenfalls nutzen, da ja eine Linearität gegeben ist. Sollte die gleiche Laufzeit haben.
:
Bearbeitet durch User
Beitrag #5514805 wurde von einem Moderator gelöscht.
Wenn Du im Ringpuffer in jeden Record einen Zähler oder Zeitstempel einfügst, kannst Du danach binär suchen.
Rolf M. schrieb: > Aber immerhin ist in der SD-Spezifikation explizit erwähnt, dass sich > die Controller auf eine ganz bestimmte Formatierung und Partitionierung > verlassen dürfen. Dann würde ich nochmal genauer lesen. Adam P. schrieb: > Mhh... ok, dann hab ich mit meinem RAW-Data-System wohl schlechte > Karten, wenn die SD-Karten das Wear-Leveling nur bei FAT erkennen und > durchführen. Nein. Das Wear-Leveling findet auf Sektorebene statt und ist unabhängig vom Filesystem.
Carduser schrieb: > Nein. Das Wear-Leveling findet auf Sektorebene statt und ist unabhängig > vom Filesystem. Also könnte ich z.B. immer in Page 4096 mein aktuellen "Zeiger" bzw. aktuelle Page schreiben und die SD-Karte würde mir die häufigen Schreibzugriffe dann intern umlagern?
Verlasse dich lieber nur auf das FAT Filesystem. Ich hatte schon einige Karten in der Hand, wo in der Anleitung ausdrücklich stand, dass man die Formatierung und das Filesystem nicht ändern darf, sonst Garantieverlust. Bei der teuersten von Sony stand sogar drin, dass ausschließlich die "schnelle" Formatierung mit Windows zulässig ist, sonst Garantieverlust. Wobei diese karte 5 Jahre Garantie auf Datenintegrität hatte.
Kannst du nicht bei deiner Suche z.B. immer 1Mb auslassen? Das wären dann im schlimmsten Fall 100 Lesezugriffe. Wenn du den ersten freien Block gefunden hast, dann springst du einen zurück und suchst wie bisher die genaue Position.
kannst du an Positionen springen? Dann könnte ein etwas intelligenterer Algorithmus die Zugriffe noch weiter reduzieren: Prüfen ob bei 50MB etwas seht, wenn ja gehst du auf 75MB und prüfst dort. Wenn nein, prüfen bei 25MB. Und dann halt bei 12 oder 37, respektive 62 und 87 prüfen... Dann kannst du ja noch mit der gelesenen Block-Grösse arbeiten...
:
Bearbeitet durch User
Stefanus F. schrieb: > Ich hatte schon einige Karten in der Hand, wo in der Anleitung > ausdrücklich stand, dass man die Formatierung und das Filesystem nicht > ändern darf, sonst Garantieverlust. Das muss nun nichts mit dem "wear leveling" zu tun haben, sondern bedeutet einfach nur das Einhalten der SD-Spezifikation. Andere Dateisysteme und letztlich auch eine andere Formatierung als in der Spezifikation beschrieben bzw. vom offiziellen "SD Card Formatter" erzeugt ist halt außerhalb der Spezifikation - und vorsichtige Hersteller haben keine Lust, sich dann auf Diskussionen einzulassen.
Carduser schrieb: > Das Wear-Leveling findet auf Sektorebene statt > und ist unabhängig vom Filesystem. Ersteres ja, letzteres nein.
Ich würde industrielle SD-Karten nehmen. Z.B. von Swissbit. Die haben besseren Flash (sogar SLC) und das wichtigste, ein gut funktionierendes Wear Leveling. Damit kannst du gerne einen Sektor immer wieder beschreiben. Die Karte sorgt dafür, dass das schön verteilt wird und du nicht wirklich immer den gleichen physischen Sektor beschreibst. Und soweit ich weiss ist das auch nicht davon abhängig, ob du FAT nutzt oder nicht.
:
Bearbeitet durch User
S. R. schrieb: > Carduser schrieb: >> Das Wear-Leveling findet auf Sektorebene statt >> und ist unabhängig vom Filesystem. > > Ersteres ja, letzteres nein. Nein. Beides ja.
Mal ein Datenblatt einer Karte mit pSLC Flash. Gibt es auch mit SLC was die Anzahl der Erasezyklen nochmal deutlich erhöht.
Marc V. schrieb: > S. R. schrieb: >> Carduser schrieb: >>> Das Wear-Leveling findet auf Sektorebene statt >>> und ist unabhängig vom Filesystem. >> >> Ersteres ja, letzteres nein. > > Nein. > Beides ja. Der Controller darf beliebig genau auf das verwendete Dateisystem optimieren, denn das Dateisystem ist genau spezifiziert. Alles andere ist außerhalb der Spezifikation und darf beliebig kaputt gehen. Wir hatten die Diskussion schon oft genug.
Marc V. schrieb: > S. R. schrieb: >> Carduser schrieb: >>> Das Wear-Leveling findet auf Sektorebene statt >>> und ist unabhängig vom Filesystem. >> >> Ersteres ja, letzteres nein. > > Nein. > Beides ja. Nein, es ist in der Bösen Realität ganz genau so, wie S.R. schrieb. Ja, das wear-leveling findet auf Sektorebene statt und ja, es hängt durchaus vom Filesystem ab. Sogar sehr stark. Tatsächlich ist es nämlich so, dass diese ganzen schrottigen (bzw. im Preiskampf ausgereizten) SD-Flash-Controller wear-levelling überhaupt nur noch für den logischen Bereich von Sektoren umsetzen, in dem sie die FAT vermuten. Das klappt tatsächlich einigermaßen gut, solange es tatsächlich ein FAT-FS ist und die FAT tatsächlich dort liegt, wo die Controller sie vermuten. Sprich: solange die vorgegebene Formatierung benutzt wird und der "Datenbereich" im Prinzip nur wächst. Das sind die schlimmsten. Und gleichzeitig auch die überwältigende Mehrheit dessen, was du heute kaufen kannst... Die besseren (die gibt es auch, man erkennt sie definitiv am deutlich höheren Preis, leider gilt der Umkehrschluss aber nicht: auch teuer kann völliger Schrott sein). Bei den tatsächlich besseren ist es jedenfalls so, dass sie tatsächlich wear-levelling über den gesamten Bereich machen, allerdings wird der Bereich der vermuteten FAT auch bei denen immer noch deutlich bevorzugt behandelt, nämlich mit erheblich feinerer Granularität. Das ist nämlich der eigentliche Knackpunkt und Kostentreiber. Um wear-leveling zu machen, brauchst du Speicher, in dem du die Historie der Nutzung aufzeichnen kannst. Dieser Speicher wird umso größer, je geringer die Granularität ist und er geht von dem insgesamt verfügbaren (und für Geld eingekauften) ab, denn er erscheint nicht in der Beschreibung, für die es letztlich Geld gibt, also in dem, wo dann DAU-Dummdödel bei Amazon oder sonstwo letztlich auf "kaufen" klickt... Die allerbesten Controller (nochmal merklich teurer) machen echtes, sozusagen vollkommen "inhaltsneutrales" wear-leveling, also über den gesamten Speicher hinweg. Man muss aber eher sagen: "machten", denn aktuell kenne ich nicht einen Vertreter mehr. Jedenfalls nicht im Bereich der aktuell möglichen Speicherkapazität... Und auch keine zwei Stufen darunter... Erst bei einem Achtel findet man noch die guten Sachen. Die kosten dann aber eben auch immer noch mehr als der aktuelle Consumer-Gammel mit der achtfachen Nennkapazität. Das allerdings ist dann wiederum nicht allein den Hardwarekosten anzulasten, sondern der schlichten Tatsache, dass es Exoten sind, von jeher in eher kleiner Stückzahl gefertigt und nun auch noch zunehmend rarer werdend, weil nur noch das Lager abverkauft wird... Insgesamt: Flash-Medien sind weit überwiegend Beschiss! Verbrauchsware wie Klopapier, keine ernstzunehenden Speichermedien. Nur SSDs sind besser. Die verhalten sich von vornherein so "inhaltsneutral" wie nur die allerbesten Vertreter des Rests der Sippschaft. Scheißegal, ob USB-Stick, SD-Card oder was auch immer. Fast alles kompletter Schrott.
c-hater schrieb: > dass diese ganzen schrottigen (bzw. im Preiskampf ausgereizten) > SD-Flash-Controller wear-levelling überhaupt nur noch für den logischen > Bereich von Sektoren umsetzen, in dem sie die FAT vermuten. Diese Erkenntnis hast Du wo gewonnen? Hast Du Dir die Firmware von SD-Flash-Controllern angesehen, und wenn ja, wie bist Du da 'rangekommen? Oder ist das nur eine Behauptung, die in Dein verschrobenes Weltbild passt?
Wie immer wurden hier mehrere unterschiedliche Varianten vom Wear Levelling erläutert. Leider kann Otto Normalverbraucher damit nichts anfangen, denn bei keiner handelsüblichen SD Karte steht irgendwo in der Anleitung, welche Variante sie unterstützt. Auch der Preis ist kein sicheres Erkennungsmerkmal. Daher rate ich dazu, die Karten nicht umzuformatieren und sie nur bestimmungsgemäß zu verwenden, wenn einem die Daten wichtig sind.
Oder ein Dateisystem nehmen das an sich Wearleveling macht. Da gabs doch was für den Raspberry Pi... Für einen direkt programmierten uC ist das wohl nicht so leicht machbar. Aber zur Frage - Wenn deine 100MB am Anfang alle Nulls sind, dann ist die binäre Suche ideal. Wie oben beschrieben, bei 50mb testen, dann bei 25, bei 12.5 usw bis mal keine null drin steht.
c-hater schrieb: > Tatsächlich ist es nämlich so [...] > überhaupt > nur noch für den logischen Bereich von Sektoren umsetzen, in dem sie die > FAT vermuten. > [...] > Bei den tatsächlich besseren ist es jedenfalls > so, dass sie tatsächlich wear-levelling über den gesamten Bereich > machen, allerdings wird der Bereich der vermuteten FAT auch bei denen > immer noch deutlich bevorzugt behandelt Hast Du Insider Informationen? Kannst Du irgend einen Link nennen wo man das gesagte mal nachlesen kann? Die Hersteller scheinen sich nämlich allesamt gründlich auszuschweigen was dieses Thema betrifft. Insbesondere würde mich interessieren welche Karten ich kaufen soll, welche nicht, und wo ich nachlesen kann was zum Beispiel Karte X (z.B. SanDisk oder was auch immmer man zu zu kaufen bekommt) nun wirklich genau macht oder zum Beispiel auch was ich am besten in den SD-Slot eines Raspberry stecke, etc.
Bernd K. schrieb: > Kannst Du irgend einen Link nennen wo man das gesagte mal nachlesen kann Das angehängte Datenblatt weiter oben vielleicht?
Wenn du dann die "ideale" Karte gefunden hast, merkst du womöglich, dass sie nicht im SPI Modus funktioniert. Das kann dann nämlich auch noch passieren. Auch das steht auf keiner (mir bekannten) Verpackung drauf.
Bernd K. schrieb: > Insbesondere würde mich interessieren welche Karten ich kaufen soll, > welche nicht, und wo ich nachlesen kann was zum Beispiel Karte X (z.B. > SanDisk oder was auch immmer man zu zu kaufen bekommt) nun wirklich Ob man es glaubt oder nicht - Wear leveling angewendet auf alle Sektoren ist viel einfacher und sicherer als wear leveling auf z.B. nur FAT und Directory Sektoren. Und daß es davon abhängt, welches Filesystem verwendet wird, stimmt bestimmt nicht. Mal angenommen, bei einem Excel file werden immer die selben 4 Zellen periodisch (30s Interval) verändert und Excel wird unmittelbar danach per VBA auf die SD-Card geschrieben. FAT bleibt unverändert, Directory Eintrag wird (aber nicht zwingend) verändert und irgendein Sektor der zu diesem File gehört, wird immer wieder neu beschrieben. Wie wird das also gehandhabt ? Laut Experten hier werden nur FAT und Directory beobachtet. Falls es doch nicht so ist, muß jeder Sektor beobachtet werden, oder ? Und wo wird das dann gemerkt ? Also nix ist mit nur FAT und Directory, nix ist mit jeder Sektor wird beobachtet - was bleibt dann ?
:
Bearbeitet durch User
Alex G. schrieb: > Oder ein Dateisystem nehmen das an sich Wearleveling macht. Das kann böse in die Hose gehen, wenn das Wear-Levelling des Dateisystems überhaupt nicht zum Wear-Levelling des Controllers passt. Allerdings findet man zu jedem Algorithmus bestimmte pathologische Verhaltensweisen. Wenn du f2fs (das Flash-Friendly Filesystem von Samsung) meinst, das ist genau so entworfen worden, um ähnliche Zugriffsmuster wie FAT zu produzieren. Um genau den Effekt des vom c-hater beschriebenen "wir sichern die FAT besonders ab, der Rest stirbt dann zuerst" zu vermeiden. Rufus Τ. F. schrieb: > Diese Erkenntnis hast Du wo gewonnen? Es gab (gibt?) SD-Karten, wo für die beiden Bereiche unterschiedliche Flash-Technologien benutzt wurden, also SLC am Anfang und MLC für den Rest. Ich glaube zwar nicht, dass das noch irgendwo gemacht wird, aber das ist schon eine deutliche Optimierung für FAT. Außerdem gibt es Erfahrungsberichte von SD-Karten, die für bestimmte Operationen unter Windows XP deutlich schneller liefen als unter Linux (oder Windows Vista). Die Controllerfirmware war nicht nur auf das verwendete Dateisystem optimiert, sondern auch speziell auf die Zugriffsmuster des FAT-Treibers von Windows XP. Ein paar interne Firmware-Tools für SD-Karten haben ihren Weg ins Internet gefunden, aber die wirken nicht unbedingt sehr hilfreich. Was man an denen sehen kann ist aber, dass die Firmwares sehr viele Tunables haben. Bernd K. schrieb: > Insbesondere würde mich interessieren welche Karten > ich kaufen soll, welche nicht, Das ist sehr schwierig. Der verbaute Flash ist das, was der Hersteller für diese Charge gerade verfügbar hatte, und die Controllerfirmware ist darauf mehr oder weniger abgestimmt. Die nächste Charge der gleichen Karte kann wieder völlig anders funktionieren. Zudem sind viele Fälschungen unterwegs. > und wo ich nachlesen kann was zum Beispiel Karte X (z.B. SanDisk > oder was auch immmer man zu zu kaufen bekommt) nun wirklich > genau macht Auch dazu wirst du keine Informationen finden, denn - wie du korrekt festgestellt hast - die Hersteller halten sich extrem bedeckt. Außerdem sind Informationen zu einer Karte nur sehr begrenzt auf andere Karten übertragbar. Einer von den Moderatoren (Lothar oder Rufus?) hatte mal längere Testreihen gemacht und lustige Effekte festgestellt. > oder zum Beispiel auch was ich am besten in den SD-Slot > eines Raspberry stecke, etc. In solchen Anwendungsfällen, wo die SD-Karte also definitiv out-of-spec betrieben wird, kommen noch ganz andere Ausfallszenarien zum Vorschein, die hier im Forum schon öfter beschrieben wurden.
Marc V. schrieb: > Ob man es glaubt oder nicht - Wear leveling angewendet auf alle > Sektoren ist viel einfacher und sicherer als wear leveling auf z.B. > nur FAT und Directory Sektoren. Aber auch deutlich bescheuerter, wenn sich die Zugriffsmuster zwischen FAT und Datenbereich deutlich unterscheiden. Was der Fall ist. > Und daß es davon abhängt, welches Filesystem verwendet wird, stimmt > bestimmt nicht. Und woher weißt du das? > Laut Experten hier werden nur FAT und Directory beobachtet. Deine Lesefähigkeiten sind mal wieder hervorragend. Es gibt zwischen "perfektes Wear-Levelling" und "kein Wear-Levelling" einen sehr großen Bereich, der eine Kompromisslösung zwischen Aufwand, Flashverbrauch, Geschwindigkeit und Zuverlässigkeit darstellt. Den Datenbereich komplett ohne Wear-Levelling zu betreiben ist für die wichtigsten Anwendungsfälle (Fotoapparat, Videokamera) vollkommen akzeptabel. Da kannst du einen drauf heben, dass das mindestens einmal auch so gemacht und verkauft wurde. Aus ungültigen Prämissen zieht man immer unzulässige Schlüsse.
> Und daß es davon abhängt, welches Filesystem > verwendet wird, stimmt bestimmt nicht. Woher glaubst du das zu wissen? Und warum (denkst du) warnt Sony Marken-Hersteller in einer Bedienungsanleitung von einer besonders hochwertigen und teuren SD Karte davor, die Partitionierung oder das Filesystem zu ändern, mit dem ausdrücklichen Hinweis, dass dies die Lebensdauer der Karte drastisch reduzieren kann? Meinst du die machen das, um ihre Kunden zu erschrecken?
S. R. schrieb: >> Und daß es davon abhängt, welches Filesystem verwendet wird, stimmt >> bestimmt nicht. > > Und woher weißt du das? Und woher weißt du, daß es nicht so ist ? Stefanus F. schrieb: > Und warum (denkst du) warnt Sony Marken-Hersteller in einer > Bedienungsanleitung von einer besonders hochwertigen und teuren SD Karte > davor, die Partitionierung oder das Filesystem zu ändern, mit dem > ausdrücklichen Hinweis, dass dies die Lebensdauer der Karte drastisch > reduzieren kann? Meinst du die machen das, um ihre Kunden zu > erschrecken? Welche Karte, wo wird gewarnt, welcher Idiot kauft so etwas, schon mal was von lebenslanger Garantie für SD Karten gehört ?
:
Bearbeitet durch User
Marc V. schrieb: > Und woher weißt du, daß es nicht so ist ? Aha, wir sind jetzt also auf dem Kinderspielplatz angekommen. Ich bin dann mal raus. Wenn du kommst, ist das Thema durch. Stichwort passiv-agressiv und so.
> Und woher weißt du, daß es nicht so ist ?
Ich gehe nicht davon aus, das ganze Produktkategorien bei allen
Herstellern bestimmte Features haben, nur weil sie gut vorstellbar wären
ich sie toll fände.
Ganz im Gegenteil beobachte ich allgemein, dass Hersteller ihre Produkte
zunehmen absichtlich so konstruieren, dass sie möglich schnell nach
Ablauf der Garantie kaputt gehen.
Wenn wenigstens die meisten dein generisches wear-levelling irgendwo
bewerben oder erwähnen würden, könnte man das mit Mut zur Lücke auf alle
Marken münzen, aber solche Hinweise habe ich jedenfalls nicht ein
einziges mal gesehen.
Stefanus F. schrieb: > Woher glaubst du das zu wissen? Fast niemand in diesem Thread kann sein "Wissen" belegen. Alles nur Glaube und gehört zu haben. Wie üblich bei diesem Thema. Ich würde mich auf das Datenblatt des Herstellers verlassen. Steht da was nicht genau genug drin oder fehlt, dann kann ich entweder nachfragen oder einen anderen Hersteller nehmen. Oder ich gehe einfach das Risiko ein dass die Karte "schnell" defekt ist wenn es nicht darauf ankommt.
S. R. schrieb: > Marc V. schrieb: >> Und woher weißt du, daß es nicht so ist ? > > Aha, wir sind jetzt also auf dem Kinderspielplatz angekommen. > Ich bin dann mal raus. Wenn du kommst, ist das Thema durch. > Stichwort passiv-agressiv und so. Selber nichts beweisen bzw. belegen können aber die anderen sollen den Gegenbeweis liefern. Sonst ist es für dich ein passiv-agresiver Kinderspielplatz. LOL.
Adam P. schrieb: > ich möchte Logs auf einer microSD ablegen. Das Problem ist mir nicht klar. Mein Akkutester baut auf Arduino, da speichere ich Zeit, Spannung und Strom auf eine SD-Karte. Die Karte ist FAT-formatiert, ich habe die "SD.h" eingebunden und schreibe einfach, landet immer am Ende der Datei. Natürlich wird die Datei nach jedem Schreibvorgang geschlossen. Wenn man will, kann man die Karte auch lesen und sicher auch ermiteln, wie groß die Datei ist.
Es gibt Unterschiede zwischen den Filesystemen. Vergleich: fat/fat16/... exFAT. letzteres benötigt wesentlich weniger Schreibzugriffe auf den entsprechenden Sektoren. (free sector bitmap)
Marc V. schrieb: > Mal angenommen, bei einem Excel file werden immer die selben 4 Zellen > periodisch (30s Interval) verändert und Excel wird unmittelbar danach > per VBA auf die SD-Card geschrieben. Das ist aber kein Standard-Anwendungsfall für SD-Karten. Der wäre eher: Ich stecke die Karte in meine Kamera und fülle sie mit Fotos. Wenn sie voll ist, verschiebe ich die Fotos auf meinen Rechner und stecke die Karte wieder in die Kamera. Jedes Foto wird einmal geschrieben und einmal gelesen, und mehr nicht. Ich würde bei dem von dir beschriebenen Szenario erwarten, dass die Karte ziemlich schnell kaputt geht. S. R. schrieb: > Außerdem gibt es Erfahrungsberichte von SD-Karten, die für bestimmte > Operationen unter Windows XP deutlich schneller liefen als unter Linux > (oder Windows Vista). Die Controllerfirmware war nicht nur auf das > verwendete Dateisystem optimiert, sondern auch speziell auf die > Zugriffsmuster des FAT-Treibers von Windows XP. Das ist ja dann wohl auch so ein Benchmark-Schummeltrick. Meist setzt man solche Karten ja viel in Geräten ein, auf denen kein Windows läuft. Aber da man den Benchmark im Windows-PC macht, bekommt man so die größten Zahlen. Marc V. schrieb: > Welche Karte, wo wird gewarnt, welcher Idiot kauft so etwas, schon mal > was von lebenslanger Garantie für SD Karten gehört ? Ob jemand ein Idiot ist, nur weil er die Karten von dem Hersteller kauft, der so ehrlich ist, etwas ins Handbuch zu schreiben, das die anderen einfach verschweigen, sei mal dahin gestellt.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.