Hi ich hatte ca. 1 Monat eine Kingston microSD 16GB/U1 in meinem Raspberry PI3 im Einsatz. Desktop Raspbian. Nach einem Reboot (reboot <enter> in der Konsole, NICHT den Stecker gezogen) kam der PI nicht mehr hoch. Nach kurzer Fehlersuche habe ich festgestellt, die SD Karte ist dauerhaft beschädigt... D.h. nicht das Filesystem drauf, sondern die komplette SD Karte! Wenn ich sie im Laptop anschließe (egal ob über den SDXC Slot oder externen Leser), wird mir nur noch lapidarisch angezeigt: 2017-07-12T00:17:57.989020-05:00 dell kernel: [958910.581793] scsi 27:0:0:0: Direct-Access MXT-USB Storage Device 1308 PQ: 0 ANSI: 0 CCS 2017-07-12T00:17:57.989037-05:00 dell kernel: [958910.582009] sd 27:0:0:0: Attached scsi generic sg1 type 0 2017-07-12T00:17:57.990027-05:00 dell kernel: [958910.582627] sd 27:0:0:0: [sdb] 491008 512-byte logical blocks: (251 MB/240 MiB) 2017-07-12T00:17:57.990038-05:00 dell kernel: [958910.582742] sd 27:0:0:0: [sdb] Write Protect is off 2017-07-12T00:17:57.990039-05:00 dell kernel: [958910.582745] sd 27:0:0:0: [sdb] Mode Sense: 03 00 00 00 2017-07-12T00:17:57.990040-05:00 dell kernel: [958910.582862] sd 27:0:0:0: [sdb] No Caching mode page found 2017-07-12T00:17:57.990041-05:00 dell kernel: [958910.582865] sd 27:0:0:0: [sdb] Assuming drive cache: write through 2017-07-12T00:18:06.650038-05:00 dell kernel: [958919.243396] usb 2-2: USB disconnect, device number 54 2017-07-12T00:18:06.655173-05:00 dell kernel: [958919.249260] sd 27:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK 2017-07-12T00:18:06.655185-05:00 dell kernel: [958919.249264] sd 27:0:0:0: [sdb] tag#0 CDB: Read(10) 28 00 00 00 00 00 00 00 08 00 2017-07-12T00:18:06.655187-05:00 dell kernel: [958919.249266] blk_update_request: I/O error, dev sdb, sector 0 2017-07-12T00:18:06.655188-05:00 dell kernel: [958919.249269] Buffer I/O error on dev sdb, logical block 0, async page read 2017-07-12T00:18:06.655189-05:00 dell kernel: [958919.249318] ldm_validate_partition_table(): Disk read failed. 2017-07-12T00:18:06.655189-05:00 dell kernel: [958919.249330] Dev sdb: unable to read RDB block 0 2017-07-12T00:18:06.655190-05:00 dell kernel: [958919.249346] sdb: unable to read partition table ... die Karte wurde zuvor angezeigt als: [sdb] 30343168 512-byte logical blocks: (15.5 GB/14.5 GiB) jetzt ist sie sozusagen tot. Kann auch nicht mehr neu formatiert werden. Ein dd auf die SD Karte scheitert mit Fehler. usw. Eine kurze Mail an den Kingston support brachte folgende Antwort: ----------- thank you for your query. Please note that any Flash based Product can get damaged, when Power is lost in a read/write cycle. In order to overcome this SSD have a Firmware based Powerloss Management or even physical capacitors. Although it may be possible to run a OS of a microSD or SD Card, the off shelve cards are neither officially tested nor officially supported for such usage. The key for the success rate depends on Controller support of turning removable Flashcard to fixed drive. This has to be evaluated and tested by yourself and each time you are purchasing a new batch or revision, it has to be re-evaluated. Alternative would be our Industrial Grade MicroSD, which will have a selected range of Controller and Nand combinations and the revision stays the same, this will make the re-evaluating obsolete. Under warranty we can only offer you a like for like replacement. We are looking forward for your reply. Best regards Bala ------------------------------------------------------------------------ ---- Kingston Technology Europe Co LLP European Technical Support Email: eu_technical@kingston.eu ------------------------------------------------------------------------ ---- Mit anderen Worten: Kingston behauptet ihre Karten können durch einen Reset / poweroff während drauf geschrieben wird, permanent zerstört werden! Wie kann das sein? Ich habe noch nie gehört daß Flash speicher physikalisch zerstört wird, wenn die Spannung während des Schreibvorgangs ausgeschaltet wird. Es berichten zwar User über Flash corruption bei den AVRs z.b., wenn bei zu niedriger Spannung geschrieben wurde (ohne brownout protection), diese AVRs lassen sich dann aber nochmal neu flashen. Wie kann das also sein, daß eine SD Karte komplett hopps geht? Beim soft-reboot (von der console) wird doch nicht mal die SPannungsversorgung unterbrochen. Hat Kingston Mist gebaut? Ich könnte mir vorstellen, daß die Karte irgendwelche internen Verwaltungsinformationen selbst im Flash ablegt. Wenn diese Daten kaputt sind, wird der interne Controller "dumm" und meldet sich nicht mehr / nicht mehr richtig. Wenn man aber so was programmiert, müßte man doch irgendeine power-safe Technik verwenden, z.b. double buffering (alte Informationen werden erst gelöscht, wenn neuer interner Record angelegt wurde, o.ä.). Ist jemanden schon so was ähnliches passiert? Bei dieser Behauptung von Kingston müßten doch täglich Millionen von SD Karten kaputt gehen. Welcher User schaltet schon sein Smartphone aus um die Karte zu ziehen? Bitte um Aufklärung... VG.
Piter K. schrieb: > ich hatte ca. 1 Monat eine Kingston microSD 16GB/U1 Kingston verbaut den billigsten Flash im Markt - die Dinger gehen relativ bald kaputt, und haben eher wechselhafte Qualität. Versuche es mal mit Sandisk oder Samsung, die haben eigene Flash Produktion am Laufen. Piter K. schrieb: > Mit anderen Worten: Kingston behauptet ihre Karten können durch einen > Reset / poweroff während drauf geschrieben wird, permanent zerstört > werden! Korekt, wenn er im kritischen Zeitfenster beim Schreibzugriff passiert. Ich habe hier bei der Firmwareentwicklung bei einem µC vor ein paar Jahren einige µSD Karten zerschossen. Hintergrund ist das die Karten ein Wear Leveling und Defekt Management machen müssen (billigster ungetesteter Flash, s.o). Wenn dabei die Verwaltungsdaten verloren gehen wars das.
Mir ist eine andere Karte auch schon "kaputt" gegangen. Vermutlich, weil ich den Stecker ziehen musste, weil der PI hing. Ich konnte die SD-Karte aber formatieren bzw. neu bespielen und funktionierte danach wieder. Vorherige Daten waren natürlich weg aber zum Glück hatte ich ein Backup. Seit dem habe ich ein "Power-Management" gelötet. Ein einziger Taster zum runterfahren und wieder hochfahren. Wenn jemand an der Lösung interessiert ist, poste ich sie gerne. Schaltplan, Ursprungsforumspost, Bilder von meiner Lösung.
So eine SD-Karte ist kein "nacktes Flash", sondern darin ist ein Controller enthalten, der u.a. für das "wear-leveling" zuständig ist. Um das machen zu können, benutzt dieser Controller von außen unsichtbare Verwaltungsinformationen, die natürlich auch irgendwo im Flash gespeichert werden müssen. Wenn beim Aktualisieren dieser Informationen das Schreiben unterbrochen wird, sind die Verwaltungsinformationen zerstört und der Controller wird Probleme haben, die Zuordnung physischer Flash-Block zu via SD-Interface adressierbarem Flash-Block herstellen zu können. > Beim soft-reboot (von der console) wird doch nicht mal die > SPannungsversorgung unterbrochen. Eben. Dann kann der Controller in der Karte seine Aktivitäten problemlos zu Ende bringen. > Welcher User schaltet schon sein Smartphone aus um die Karte zu ziehen? Muss man ja auch nicht, die werden ja nicht ständig beschrieben.
Nun ich habe erstmal die Marke gewechselt zu Sandisk. Mal sehen. Für mich ist das bad engineering was Kingston da macht.
Jim M. schrieb: > Kingston verbaut den billigsten Flash im Markt - die Dinger gehen > relativ bald kaputt, und haben eher wechselhafte Qualität. interessante fakten zum thema: https://www.youtube.com/watch?v=ruEn7TE4YMM
H. E. schrieb: > Mir ist eine andere Karte auch schon "kaputt" gegangen. Vermutlich, weil > ich den Stecker ziehen musste, weil der PI hing. Ich konnte die SD-Karte > aber formatieren bzw. neu bespielen und funktionierte danach wieder. > Vorherige Daten waren natürlich weg aber zum Glück hatte ich ein Backup. > Das wäre ja ok, selbst bei einer Magnetplatte kann man sich die Daten drauf kaputt machen, wenn man den Stecker zieht... aber die Platte selbst?! Ich habe auch einen Backup von meinem PI, nur dummerweise kann ich es nicht zurück spielen auf die SD-Karte. Die meldet sich nur noch als 251MB anstatt 14.9G und ist auch nicht mehr bespielbar (nicht mal die 251MB). Fehler beim Zugriff auf Sektor 0..... das war's. Ein Design-Fehler würde ich sagen. Den verantwortlichen Ingenieur sofort feuern!!! aber halt mal.... so ein "Bug" (oder Feature) kurbelt doch den Absatz an neuen SD Karten an....
Piter K. schrieb: > Das wäre ja ok, selbst bei einer Magnetplatte kann man sich die Daten > drauf kaputt machen, wenn man den Stecker zieht... aber die Platte > selbst?! Die hat einen ähnlichen Fehlermode, aber mit um Größenordnungen niedrigerer Wahrscheinlichkeit. Auch da sind die Verwaltungsdaten auf dem Medium (Platten) und können versehentlich verloren gehen. Das ergibt das Klack-klack-klack Geräsuch beim Plattentod. Wegen der - durchaus nutzbaren - mechanischen Energie im Plattenstapel kommt das in der Praxis aber nur vor wenn die Platte auch anderswo schon Daten verliert, lies die Magnetisierung schlecht wird.
Piter K. schrieb: > jetzt ist sie sozusagen tot. Kann auch nicht mehr neu formatiert werden. > Ein dd auf die SD Karte scheitert mit Fehler. usw. Probiere mal, ob sich diese SD-Karte noch mit dem "SD Card Formatter" formatieren Läßt. https://www.sdcard.org/downloads/formatter_4/
Piter K. schrieb: > Ein Design-Fehler würde ich sagen. Den verantwortlichen Ingenieur sofort > feuern!!! Erzähl nicht so einen Quatsch. Wenn man billigst kauft, bekommt man eben keine Top-Qualität. Der Ingenieur, der so ein billiges und dennoch funktionsfähiges Medium entwickelt, solle wohl eher extra verdienen. Du bist selber schuld, wenn du ungeeignetes Material verwendest. Genau das gleiche Spiel beim "Abgasskandal" - jetzt meckern alle dass die bösen Ingenieure/Manager fiese Dinge getan haben, aber wenn die Motoren billig und die Aktienerlöse hoch sind haben sich noch alle gefreut.
Dr. Sommer schrieb: > Piter K. schrieb: >> Ein Design-Fehler würde ich sagen. Den verantwortlichen Ingenieur sofort >> feuern!!! > Erzähl nicht so einen Quatsch. Wenn man billigst kauft, bekommt man eben > keine Top-Qualität. Eigentlich dachte ich ein Prämium-Produkt zu kaufen... so war bislang meine Meinung von Kingston. Und billig war's wirklich nicht. Eine China-Marke hätte es für die Hälfte des Kingston-Preises getan.
> Youtube-Video "30C3: > The Exploration and Exploitation of an SD Memory Card (EN)" Für die, die keine Lust auf das Video haben: https://www.bunniestudios.com/blog/?p=3554
Vielleicht ist ja auch gar nicht die Karte das Problem, sondern ihr Einsatz. Ich lese, im Netz, öfters was von geschrotteten SD-Karten am Raspberry. Ist es in einem Forum, verläuft die Diskussion ähnlich wie hier. Mein (persönlicher) Verdacht ist, das übliche SD-Karten einfach nicht als Systemdatenträger geeignet sind. Der normale Einsatzort ist als Datenspeicher in einer Digitalkamera, einem MP3-Player, Audiorekorder, ... Wie oft werden da Daten neu geschrieben? Beim dauerhaften Einsatz als Systemdatenträger ist es ein Vielfaches davon. Ich denke, die Karten werden einfach kaputtgeschrieben. So toll der Raspberry auch ist, das macht ihn mir suspekt, an dieser Stelle ist der Ausfall vorprogrammiert. Das ist ein grundsätzliches Problem bei der Verwendung eines Smartphone-SoC, da gibt es keine Schnittstelle für einen 'richtigen' Massenspeicher, wie z.B. eine SSD. SSDs sind für die Verwendung als Systemdatenträger ausgelegt, durch passende Auswahl der FLASH-Chips und eine recht große Zahl von Reserve-Speicherblöcken. Mit freundlichen Grüßen - Martin
Martin S. schrieb: > Mein > (persönlicher) Verdacht ist, das übliche SD-Karten einfach nicht als > Systemdatenträger geeignet sind. Sind sie auch nicht. Man kann schon bei der Formatierung viel falsch machen, denn die Dinger haben interne Blockgrößen von 4MB(SDHC). Da müsste man bei modernen Filesystemem viel rechnen um die Blöcke zu alignen - das macht per default kein Tool außer dem o.g. SD Formatter, und der geht nur für FAT16/32/ExFAT. Martin S. schrieb: > Wie oft werden da Daten neu geschrieben? Extrem unterschiedlich - Linux kann auch aus dem RAM laufen. Wenn man an "noatime" gedacht hat und nicht viel Logging an hat muss auch nicht viel geschrieben werden. Aber schon bei mäßiger Schreiblast geht 'ne SD schnell kaputt. Übrigens sind die Haltbarkeiten enorm unterschiedlich - einige Sandisk und Samsung SD hielten "ewig", einige "NoName" hielten nicht einmal ein vollständiges Beschreiben des Mediums mit Daten aus...
Martin S. schrieb: > Vielleicht ist ja auch gar nicht die Karte das Problem, sondern ihr > Einsatz. > > Ich lese, im Netz, öfters was von geschrotteten SD-Karten am Raspberry. Was aber in meinem Fall nichts am Problem ändert, daß nicht die Flash Zellen kaputt gegangen sind, sondern eher der Controller "dumm" geworden ist durch verlorene Verwaltungsdaten. Die Karte war 1 Monat im Einsatz und viel geschrieben wurde nicht darauf. Eine Videocamera schreibt in der Zeit das 100-1000x auf eine SD Karte. Ich bin ja damit einverstanden, daß mir eventuell das Filesystem kaputt geht beim Einsatz im RPI. Dafür gibt es auch Backups. Und spezielle Filesysteme. Aber Hardware die sich selbst schrottet (vor allem durch SOFTREBOOT!) ist einfach nur UNAKZEPTABEL! Ich habe woanders in einem Ferienhaus einen RPI für die Hausüberwachung. Der rebootet seit über einem Jahr täglich um Mitternacht und bisher noch keine Probleme. Ist eine EVO32 drin... vielleicht können es einige Hersteller einfach besser?
Kannst du denn den Sektor 0 nicht neu schreiben oder löschen - bevor das OS da mit den Resten evt. etwas anzumelden versucht?
Ich habe es mit dd if=backup.sdb of=/dev/mmcblk0 count=1 versucht (backup.sdb ist ein dump der sd Karte vor der SelbstZerstörung), kann aber nicht drauf zugegriffen werden. Weder im internen SDXC Leser noch in zwei externen SD Kartenlesern. Sowohl Linux als auch ein Windows Laptop bekommt nur eine fake-Meldung (fake NEWS haha) daß die Karte nun 251MB groß ist. Kann die Karte also weder neu formatieren / partitionieren, noch das Backup drauf schreiben. Der interne Controller ist sozusagen "dumm" geworden. Es ist ja kein Block-Schreibefehler auf einen einzelnen Sektor (kein bad block), sondern die Karte meldet sich nicht mehr als 16GB :/ Wenn der Controller seine Verwaltungsdaten beim Reboot verloren hat, dann ist das definitiv ein Design-Fehler. Diese Daten sind in einem separaten Block abzulegen, der nicht mit von außen zugänglichen Blocks zusammen fällt. Und wenn dieser Block beschrieben wird, dann muss ein sauberes Design zuerst neue Daten schreiben und dann die alten als ungültig markieren (2 flash blocks benutzen). Es ist auf jeden Fall lösbar es so zu programmieren, daß ein power down nicht den Controller unbrauchbar macht wegen fehlender Verwaltungsdaten, selbst wenn der zugängliche Stand der Verwaltungsdaten nicht dem zuletzt geschriebenen entspricht. Der User verliert dann eventuell einen Teil seiner Daten kann die Karte aber neu bespielen. So wie das Kingston "gelöst" hat ist einfach nur idiotisch.
Piter K. schrieb: > Ist jemanden schon so was ähnliches passiert? Ja, ich habe vor 5 Jahren oder so eine Kingston SD so ähnlich geschrottet, aber in meiner Kamera... Ich habe meistens jetzt SanDisk oder Samsung, wobei auch China SD Karten mit einem Label (nicht NoName!) meist halten, was sie versprechen. Wir haben in der Firma USB Sticks, welche ein ganz interessantes verhalten haben, nach 2 - 3 Jahren, sind ca. 90% der Sticks von USB Sticks zu USB CD Laufwerken mutiert. Leider ist aber keine CD eingelegt, und dementsprechend kann man darauf auch nicht mehr zugreifen. Und nein, ich habe nicht versucht, eine CD einzulegen ;-) Ich vermute mal, die Controller werden nicht nur für eine Serie, sondern für mehrere Anwendungen ausgelegt, und irgendwo gibt es eine Konfiguration. Wird diese Konfiguration zerschossen, wie auch immer, dann passiert sowas... mfg Andreas
Klar, was auf OS-Ebene geht (gespiegelte Dateien, wiederherstellbare Dateisysteme), geht sicher prinzipiell auch auf Firmwarebene. Muß ja auch, da man bei Batteriegeräten sowieso jederzeit mit Stromausfall, Rausziehen von Batterien oder Karte rechnet. Aber wenn die SW-Entwicklung nach Takka-Tukkaland outgesourct ist..
Piter K. schrieb: > Und wenn dieser Block beschrieben wird, dann muss ein > sauberes Design zuerst neue Daten schreiben und dann die alten als > ungültig markieren (2 flash blocks benutzen). Genau da ist wahrscheinlich der wunde Punkt: wenn plötzlich die Spannung beim Schreiben unterbrochen wurde. Das Übel lässt sich wahrscheinlich nur umgehen wenn man 2 VERSCHIEDENE Speichermedien zu etwas unterschiedlichen Zeiten beschreibt. Die andere SD-Karte könnte dann überleben weil sie entweder früher oder noch gar nicht überschrieben wurde.
An einem Raspberry PI 1 habe ich das auch schon an einer SD-Karte von Sandisk gehabt. Datenträger hat 0 Byte Größe
oszi40 schrieb: > Piter K. schrieb: >> Und wenn dieser Block beschrieben wird, dann muss ein >> sauberes Design zuerst neue Daten schreiben und dann die alten als >> ungültig markieren (2 flash blocks benutzen). > > Genau da ist wahrscheinlich der wunde Punkt: wenn plötzlich die Spannung > beim Schreiben unterbrochen wurde. > Nun, wenn der Controller merkt, daß seine Verwaltungsdaten korrupt sind, könnte er wenigstens noch eine Option erlauben, die Karte auf den Ursprungszustand zurück zu setzen... Dann verliert man die Daten aber nicht gleich die Karte :/ Hardware die vom Stecker ziehen kaputt geht ist mir total unsympatisch. Und meiner Meinung nach liegt bei so was IMMER ein Designfehler vor.
qx schrieb: > An einem Raspberry PI 1 habe ich das auch schon an einer SD-Karte von > Sandisk gehabt. Datenträger hat 0 Byte Größe Da stellt sich die Frage ob man lieber USB sticks benutzen sollte...? Bei den neuen PIs kann man ein Fuse setzen und es soll von USB booten können (versucht habe ich es noch nicht). Zumindest von der Größe her hätte ein Stick Platz für Backup-Kondensatoren... so daß ein power down sich noch paar Millisekunden vorher an den Controller ankündigen kann. Es wäre dann nur noch eine Faule Ausrede vom Hersteller zu behaupten daß die Sticks kaputt gehen können. Ausrede für billigstes Design. Sind solche Fälle von komplett defekten USB sticks durch bloßes herausziehen bekannt? (HW defekt, nicht Daten korrupt).
H. E. schrieb: > Seit dem habe ich ein "Power-Management" gelötet. Ein einziger Taster > zum runterfahren und wieder hochfahren. > > Wenn jemand an der Lösung interessiert ist, poste ich sie gerne. > Schaltplan, Ursprungsforumspost, Bilder von meiner Lösung. Mich interessiert die Lösung. Ich hatte damals mal etwas derartiges gemacht - nur seitdem sich mit einem neuen Kernel die Pin-Steuerung aus dem Userspace entfernt hatte, habe ich es nicht mehr hinbekommen. Viele Grüße W.T.
Piter K. schrieb: > Dann verliert man die Daten aber > nicht gleich die Karte :/ Das wäre aber ökonomisch äußerst ineffektiv.
Walter Tarpan schrieb: > Mich interessiert die Lösung. Ich hatte damals mal etwas derartiges > gemacht - nur seitdem sich mit einem neuen Kernel die Pin-Steuerung aus > dem Userspace entfernt hatte, habe ich es nicht mehr hinbekommen. Die Lösung sollte immer im Device selbst sein! Wenn ich einen USB stick dran hänge, weiß der doch gar nicht, ob er gemounted ist oder nicht - das device hängt einfach nur am USB bus als block device und empfängt Befehle vom OS. Mounten ist eine reine Software-Sache. Der Stick kriegt davon gar nichts mit. Er weiß nicht, ob bald Daten kommen werden oder nicht. Andererseits weiß das OS auch nicht, ob der Stick nicht gerade irgendeine komische interne "Umverteilungsaktion" in seinem Flashspeicher fährt. Folglich gibt es keine software-seitige Möglichkeit auszuschließen, daß gerade doch was im internen Flash vorgeht (*). Deswegen muss jedes Flash device so entworfen sein, daß es nicht über den Jordan geht, wenn die Spannungsversorgung unvorhergesehen zusammenbricht. Das gilt auch für SD Karten! viele Grüße (*) das wäre zwar THEORETISCH möglich, ist aber mit den aktuellen Protokollen bei SD und USB nicht vorgesehen.
Brummbär schrieb: > Piter K. schrieb: >> Dann verliert man die Daten aber >> nicht gleich die Karte :/ > > Das wäre aber ökonomisch äußerst ineffektiv. na super.... dann sollen die DAUs den Umsatz der Unternehmen ankurbeln, nur weil man dort zu doof ist es sauber zu entwerfen? Nach der gleichen Logik wäre es doch sinnvoll, wenn jede Waschmaschine sofort kaputt gehen würde wenn man während des Schleudergangs den Stecker zieht... Wer so was bewußt entwirft hat sein Diplom nicht verdient.
Piter K. schrieb: > Die Lösung sollte immer im Device selbst sein! Ich halte die Notwendigkeit, einen Rechner vor dem Ausschalten herunterzufahren, seit Windows 95 für eine gemeinhin akzeptierte Tatsache. Es war zwar schöner, am Amiga einfach zu warten, bis die Disketten- oder Festplattenleuchte ausgegangen ist (früher war ja alles besser) - aber spätestens seit 20 Jahren leben die Benutzer damit, daß der Rechner erst heruntergefahren wird. Bei meinen Raspberry Pis ist noch nie eine SD-Karte beschädigt worden. Allerdings schon mehrmals das Dateisystem eines angeschlossenen USB-Sticks. Deswegen interessiert mich ein einfacher, aktuell funktionierender Mechanismus, den Rapsberry Pi per Knopfdruck herunterfahren zu können.
Piter K. schrieb: > Bei dieser Behauptung von Kingston müßten doch täglich Millionen von SD > Karten kaputt gehen. Welcher User schaltet schon sein Smartphone aus um > die Karte zu ziehen? Ich. Aber seis drum: ich habe hier eine ganze Kiste voller kaputt geschriebener µSD Karten und kann dir aus mittlerweile jahrelangen Dauertests (mit Dauerschreiben kleiner Dateien und dreimüntigen Ein-Ausschaltzyklen) Samsung oder XMore (von Glyn) oder auch noch Toshiba empfehlen. Die anderen in der Kiste sind von Swissbit, Kingston, Intenso, ATP, Innodisk, Sandisk, Transcend. Die empfehle ich nicht, obwohl da einige mit dem Attribut "Industrie" beworben werden... Rufus Τ. F. schrieb: > benutzt dieser Controller von außen unsichtbare Verwaltungsinformationen, > die natürlich auch irgendwo im Flash gespeichert werden müssen. Noch besser: sogar die Firmware für diesen Controller ist (logischerweise) auf dem Flash abgespeichert.
Lothar M. schrieb: > Piter K. schrieb: >> Bei dieser Behauptung von Kingston müßten doch täglich Millionen von SD >> Karten kaputt gehen. Welcher User schaltet schon sein Smartphone aus um >> die Karte zu ziehen? > Ich. > Statistisch nicht signifikant... die restlichen 99% Smartphone User sind sich keiner Schuld bewußt. > Aber seis drum: ich habe hier eine ganze Kiste voller kaputt > geschriebener µSD Karten und kann dir aus mittlerweile jahrelangen > Dauertests (mit Dauerschreiben kleiner Dateien und dreimüntigen > Ein-Ausschaltzyklen) Samsung oder XMore (von Glyn) oder auch noch > Toshiba empfehlen. > Die anderen in der Kiste sind von Swissbit, Kingston, Intenso, ATP, > Innodisk, Sandisk, Transcend. Die empfehle ich nicht, obwohl da einige > mit dem Attribut "Industrie" beworben werden... Werde ich mir merken, danke. > Rufus Τ. F. schrieb: >> benutzt dieser Controller von außen unsichtbare Verwaltungsinformationen, >> die natürlich auch irgendwo im Flash gespeichert werden müssen. > Noch besser: sogar die Firmware für diesen Controller ist > (logischerweise) auf dem Flash abgespeichert. Das muss kein Problem sein, solange man nicht den Firmware-Block löschen muss, um auf den Rest zuzugreifen. Es haben einfach keine vitalen Daten was dort zu suchen, wo ständig herum geschrieben / erased wird.
Walter Tarpan schrieb: > Piter K. schrieb: >> Die Lösung sollte immer im Device selbst sein! > > Ich halte die Notwendigkeit, einen Rechner vor dem Ausschalten > herunterzufahren, seit Windows 95 für eine gemeinhin akzeptierte > Tatsache. Rechner != SD Karte... ein Medium welches jederzeit zum herauswerfen zugänglich ist, sollte durch den Vorgang nicht PERMANENT zerstört werden dürfen. Punkt. Ich rede doch nicht von den Daten / Filesystem. Sogar CDROM Laufwerke haben den Schacht gelockt, wenn die CD gebrannt wird :)
Mein alter Herr hatte in seinem Cloud-Raspi auch mal eine Micro-SD, die sich konsequent als Wechseldatenträger mit "0 Bytes" Speicherkapazität meldete. Mein Linux-Laptop konnte sie mit fdisk dann doch wieder überzeugen, eine 32GB-Karte zu sein.
Lothar M. schrieb: > ich habe hier eine ganze Kiste voller kaputt > geschriebener µSD Karten und kann dir aus mittlerweile jahrelangen > Dauertests (mit Dauerschreiben kleiner Dateien und dreimüntigen > Ein-Ausschaltzyklen) Wie genau äußert sich denn, dass die Karten "kaputt" sind? (Bit-) Kommunikation schlägt komplett fehl? Lediglich einige Kommandos? Daten sind nicht mehr les/schreibbar?
Hi, also bei Raspi-Lösungen, die wirklich lange halten sollen, habe ich nur den Kernel von der SD-Karte booten lassen und dann wird das OS sofort von einer kleinen SSD mit USB-Snüffelstück übernommen. Dabei sollte auf die SD-Karte grundsätzlich nicht geschrieben werden müssen. Gruß, Oliver
Piter K. schrieb: > Für mich ist das bad engineering was Kingston da macht. Billiges Produkt = Bad Engineering, das ist immer so.
Mikro 7. schrieb: > Wie genau äußert sich denn, dass die Karten "kaputt" sind? > (Bit-) Kommunikation schlägt komplett fehl? Lediglich einige Kommandos? > Daten sind nicht mehr les/schreibbar? Beliebig. Es fängt im Dauertest immer damit an, dass Dateien, die eigentlich nie "angefasst" werden, ihre Daten ändern. Dann ist es nicht mehr lange, bis das Dateisystem korrupt ist oder die Karte gar nicht mehr erkannt wird.
Martin S. schrieb: > Ich lese, im Netz, öfters was von geschrotteten SD-Karten am Raspberry. > Ist es in einem Forum, verläuft die Diskussion ähnlich wie hier. Mein > (persönlicher) Verdacht ist, das übliche SD-Karten einfach nicht als > Systemdatenträger geeignet sind. Da liegt glaube ich viel am RasPi. Habe hier ein uraltes ARM-Board (noch aus der Zeit vor RasPi 1, ca 2007) das läuft 24/7 als "Home-Server" mit einer MicroSD-Karte als Root-FS-Datenträger. Vor ein paar Jahren habe ich die Karte ausgewechselt, aber nicht weil die alte EOL gewesen wäre, sondern um mehr Platz zu haben (jetzt ist's ne 16GB-Karte). > cat /sys/fs/ext4/mmcblk0p3/lifetime_write_kbytes 277588313 SWAP liegt ebenfalls auf der SD-Karte, und wird auch genutzt da nur 512MB Ram vorhanden sind. Diverse Stromausfälle sind alle folgenlos geblieben. Was vielleicht den Unterschied macht: Die Kombination MMC-Treiber & SD-Karte unterstützt TRIM/DISCARD, vmlt. auf CMD MMC_ERASE gemappt. Evtl. kann der Controller der SD-Karte damit was sinnvolles anfangen. > sudo fstrim -v / /: 1402425344 bytes were trimmed
Walter Tarpan schrieb: > Ich halte die Notwendigkeit, einen Rechner vor dem Ausschalten > herunterzufahren, seit Windows 95 für eine gemeinhin akzeptierte > Tatsache. Zu der Zeit arbeitete man noch mit Festplatten, die nicht so schnell kaputt gingen.
Lothar M. schrieb: > Es fängt im Dauertest immer damit an, dass Dateien, die eigentlich nie > "angefasst" werden, ihre Daten ändern. Dann ist es nicht mehr lange, bis > das Dateisystem korrupt ist Korruptes Dateisystem ist "normal" bei Stromausfall. Änderung von "nicht-beteiligten" Blöcken wohl auch, bei einigen (vielen?) Modellen. Das wurde ja vor kurzem in einem anderen Thread hier im Forum durchgekaut (fehlende Transaktionssicherheits in der Karte beim Löschen von Pages und Umkopieren von Blöcken). > oder die Karte gar nicht mehr erkannt wird. Das wäre eine neue Dimension. Wie identifzierst du das? Ungültiges SPI Packet, Error Response, Initialisierung, ... ?
Walter Tarpan schrieb: > H. E. schrieb: >> Seit dem habe ich ein "Power-Management" gelötet. Ein einziger Taster >> zum runterfahren und wieder hochfahren. >> >> Wenn jemand an der Lösung interessiert ist, poste ich sie gerne. >> Schaltplan, Ursprungsforumspost, Bilder von meiner Lösung. > > Mich interessiert die Lösung. Ich hatte damals mal etwas derartiges > gemacht - nur seitdem sich mit einem neuen Kernel die Pin-Steuerung aus > dem Userspace entfernt hatte, habe ich es nicht mehr hinbekommen. > > Viele Grüße > W.T. Habe dafür ein Topic eröffnet. Beitrag "PI3, Interes WakeUp, PowerManagement mit nur einem Taster" :)
Ich hatte auch einen Ausfall mit SD-Card am Raspi. Seit dem mounte ich die Karten nur noch schreibgeschützt. Für /var schließe ich einen USB-Stick an. Seit Jahren nun keine Ausfälle mehr. Wenn etwas am System geändert werden muss, mounte ich den Datenträger vorübergehend RW und stelle nach den Änderungen wieder auf RO zurück. Nachteil: Die Shell merkt sich nicht die Befehle über die Abmeldung hinaus. Damit kann ich leben. Es gibt noch die Möglichkeit über UnionFS eine RAM-Disk und den RO-Teil des Laufwerkes tranparent zu verbinden, so dass Schreibzugriffe trotzdem möglich sind. Bei mir gab's Probleme, wenn ich das mit den Home-Verzeichnissen gemacht habe, da die Verlinkungen scheinbar alle Rechte hatten und SSH so nicht die hinterlegten Schlüssel nehmen wollte. Ich mache das daher nicht mehr. Die Anleitung ist nur noch über die Wayback-Machine erreichbar: http://web.archive.org/web/20150101110424/http://raspberrycenter.de/forum/umruestung-raspberry-pi-read-only-root-filesystem
Mikro 7. schrieb: > Lothar M. schrieb: >> oder die Karte gar nicht mehr erkannt wird. > > Das wäre eine neue Dimension. Wie identifzierst du das? Ungültiges SPI > Packet, Error Response, Initialisierung, ... ? genau diese Dimension ist bei mir erreicht... Karte wird nicht mehr erkannt. Neuformatieren nicht möglich.
Piter K. schrieb: > genau diese Dimension ist bei mir erreicht... Karte wird nicht mehr > erkannt. Neuformatieren nicht möglich. Hast du jetzt mal den "SD Card Formatter" ausprobiert? https://www.sdcard.org/downloads/formatter_4/
GeraldB schrieb: > Piter K. schrieb: >> genau diese Dimension ist bei mir erreicht... Karte wird nicht mehr >> erkannt. Neuformatieren nicht möglich. > > Hast du jetzt mal den "SD Card Formatter" ausprobiert? > https://www.sdcard.org/downloads/formatter_4/ Und wie soll ich es ausprobieren, wenn die Karte nicht mehr erkannt wird? Hast meinen Beitrag nicht gelesen.
mein Englisch ist nicht das beste, bieten Sie dir nicht einen Umtausch an? Oder wollen die damit sagen das es dein beanstandetes Modell nicht mehr gibt und ein Umtausch deswegen nicht möglich ist. Under warranty we can only offer you a like for like replacement.
Thomas O. schrieb: > Under warranty we can only offer you a like for like replacement. Das bedeutet: Wenn du noch garantie hast bekommst du ein ähnliches Gerät, weils das gleich nicht mehr gibt.
:
Bearbeitet durch User
Piter K. schrieb: > Eigentlich dachte ich ein Prämium-Produkt zu kaufen... so war bislang > meine Meinung von Kingston. Und billig war's wirklich nicht. Eine > China-Marke hätte es für die Hälfte des Kingston-Preises getan. Doch, Du hast ein Billigprodukt gekauft. "Prämium"-Produkte kosten ein Vielfaches des mutmaßlich von Dir gezahlten Preises. Nur weil etwas nur doppelt so teuer ist wie andere Billigprodukte, ist es absolut gesehen ggf. trotzdem noch in der Ramschklasse angesiedelt. Mutmaßlich hochwertige USB-Speichersticks der 16GB-Klasse kosten so ab ca. US $200: https://www.amtron.com/USB_flash_disk.htm#apro_g4_prices An welcher Stelle hat Kingston Dir gegenüber ganz konkrete Aussagen über die Produktqualität getroffen? Piter K. schrieb: > Wenn ich einen USB stick dran hänge, weiß der doch gar nicht, ob er > gemounted ist oder nicht - das device hängt einfach nur am USB bus als > block device und empfängt Befehle vom OS. Mounten ist eine reine > Software-Sache. Der Stick kriegt davon gar nichts mit. Die Controller-Firmware trifft aber bestimmte Annahmen über das vom Host eingesetzte Dateisystem und richtet auch das eigene Wear Leveling darauf aus. Das kann durchaus auch bedeuten, dass die Annahmen, z.B. über die Lage und das Format der Verwaltungsstrukturen des Dateisystem, nicht mehr zutreffen, wenn der Speicherstick neu formatiert wurde, insbesondere natürlich mit einem Dateisystemtyp, den der Stick nicht erkennt. Die meisten Controller gehen von FAT-Varianten aus und betreiben dann z.B. bei ext2/3/4 gar kein Wear Leveling. Hersteller hochwertiger Speichersticks stellen durchaus auch Listen bereit, in denen die unterstützten und in Langzeittests erprobten Dateisystemtypen aufgeführt sind, allerdings nach Unterzeichnung von NDAs. Hast Du denn vor der Neuformatierung eines entsprechende Stellungnahme von Kingston eingeholt? Wie lauten denn deren verbindliche Zusagen zu den von Dir eingesetzten Dateisystemtypen? Oder hast Du den Stick etwa eigenmächtig neu formatiert bzw. mit einem nicht explizit für genau diesen Speicherstick durch den Hersteller freigegebenen Dateisystemimage bespielt?
Thomas O. schrieb: > mein Englisch ist nicht das beste, bieten Sie dir nicht einen Umtausch > an? Oder wollen die damit sagen das es dein beanstandetes Modell nicht > mehr gibt und ein Umtausch deswegen nicht möglich ist. > > Under warranty we can only offer you a like for like replacement. nun ich könnte es tauschen lassen, aber es ist in dem Flash Entwicklungszeugs drauf - Firmenpolitik läßt es nicht zu (wer weiß was der Hersteller doch noch von der Karte lesen kann?). Also bleibt nur der Shredder für die Karte und Lehrgeld verbuchen :/
Andreas S. schrieb: > Hast Du denn vor der Neuformatierung eines entsprechende Stellungnahme > von Kingston eingeholt? Wie lauten denn deren verbindliche Zusagen zu > den von Dir eingesetzten Dateisystemtypen? Oder hast Du den Stick etwa > eigenmächtig neu formatiert bzw. mit einem nicht explizit für genau > diesen Speicherstick durch den Hersteller freigegebenen Dateisystemimage > bespielt? Betrieb in RPI bedeutet nun mal KEIN FAT/VFAT voraus. FAT gibt's nur für die /boot partition, der Rest ist ext4. Wenn SD Karten so problematisch sind, sehe ich den schwarzen Peter bei RPI foundation. Frühere versionen können NUR von SD booten, bei den neueren geht es nach setzen eines Fuse auch über USB (noch nicht probiert). Und ein Wear leveling das nur bei bestimmten FS funktioniert halte ich für ein Gerücht. Wäre wieder ein Fall von bad engineering. Wenn ich mir ein FAT filesystem nicht ab sektor 2048 sondern sagen wir 4096 anlege, dann wäre zwar ein FAT drauf aber die Verwaltungsstrukturen wären schon mal ganz woanders.... das willst Du mir doch nicht wirklich weiß machen, daß die SD Karte auf ein bestimmtes Layout und Lage der Partition "optimiert" ist.... Wie man es wendet und dreht: ein Medium das jederzeit rauswurfbereit ist, DARF dabei NICHT permanent zerstört werden. Bei den meisten Geräten sind SD Slots nicht geschützt, bzw die Karte schaut teilweise heraus. Und ich bin mir sicher, daß das mit sehr wenig Aufwand in der Firmware sichergestellt werden kann. Flash geht nicht physikalisch kaputt bei brownout.
Die Ergänzung dazu von Kingston, die heute kam: ------------------------------ thank you for your reply. Smartphone and Tablets actually will notify or give a warning, if a microSD card is removed while in use. Therefore you actually have the safe remove feature or you shutdown the device, which will send command to complete any write and read operations. On Digital Cameras data is not run from flash card, unless you are viewing a Media from it and it gets only accessed when writing data to it, if you remove it in such scenario can in worst case have the same effect. Some Cameras have even a security feature to notify you, that your charge is not sufficient to complete the intended Task to avoid a shutdown during use. And as already stated the usuage as a boot drive the state of the card is also changed to a fixed mode, depending on controller and nand this can also have affect on early failure. You could try a different MicroSD Card Adapter or try connecting the microSD card directly to rule out a fault with the adapter. The phycial defekt as such, can happen in worse case, like damaged or corrupted FTL to a state that it unable to recover, so system won't be able to access the Information to show its content or the controller gets to panic state to protect data, in this state it may not be visible for User, but a datarecovery company maybe to access data using a MP tool. Under warranty we can offer you a replacement for 1x SDC10/16GB like for like. We would recommend to use the industrial grade microSD Card for your type of usage scenarios. In order to proceed with the replacement, please provide us with your full name, address and telephone number. We are looking forward for your reply. Best regards ------------------------------- Mit anderen Worten: Gerede um den heißen Brei, gespickt mit Halbinformationen. Übersetzung: "ist halt so und wir können es nur umtauschen, ansonsten bitte zu industrial grade SD Karte greifen". Nun jetzt weiß ich, was ich von dieser Firma halten soll.
Piter K. schrieb: > Wenn SD Karten so problematisch sind, sehe ich den schwarzen Peter bei > RPI foundation. Frühere versionen können NUR von SD booten, bei den > neueren geht es nach setzen eines Fuse auch über USB (noch nicht > probiert). Der RPi ist für Schul- und Ausbildungszwecke konzipiert, und damit vor allem eins: billig. Man hat quasi das Beagleboard genommen und alles weggelassen was nicht überlebensnotwendig ist. Das die Dinger mal als Steuerungsrechner 24/7 durchlaufen hat sich seinerzeit keiner vorstellen können. > Und ein Wear leveling das nur bei bestimmten FS funktioniert halte ich > für ein Gerücht. Wear levelling unsterstellt einen bestimmten use case. Und der war zu Beginn der SD-Ära sequenzielles Vollschreiben und anschließende Komplettlöschung -- halt das was eine typische Kamera macht. Auf wahlfreien Schreibzugriff waren früher nur die Industrie-Serien ausgelegt. Heute mag das anders sein, hängt aber stark vom Hersteller ab. Und gerade Billighersteller investieren nicht unbedingt Unsummen in die Entwicklung robuster Algorithmen. > Wie man es wendet und dreht: ein Medium das jederzeit rauswurfbereit > ist, DARF dabei NICHT permanent zerstört werden. Bei den meisten Geräten > sind SD Slots nicht geschützt, bzw die Karte schaut teilweise heraus. > Und ich bin mir sicher, daß das mit sehr wenig Aufwand in der Firmware > sichergestellt werden kann. Flash geht nicht physikalisch kaputt bei > brownout. Neben den Daten werden im Flash auch Verwaltungsinformationen gespeichert. Welche Blöcke sind kaputt, mit welchem Namen und welcher Kapazität meldet man sich am Bus, teilweise sind da sogar Teile der Controller-FW abgelegt. Wenn Du die durch einen Schreibunfall zerstörst, brauchst Du das Herstellertool um die Karte neu zu konfigurieren. Das gilt für Magnetplatten überigens auch. Die haben Konfiguration und Teile der Firmware auf der Magnetscheibe gespeichert, und wenn da der Kopf aufschlägt ist Feierabend.
Ich sehe gerade solche "Industrial grade " Karten werden für teuer angeboten, dabei ist es in 99% der Fälle ein SLC Flash (was die Sache teuer macht). Dazu kommen noch IP67, shock proof, Xray proof, etc etc... (fehlt nur noch bullet proof)... alles Features, die ich hier zum Entwickeln nicht brauche. Und eine microSD Karte als "industrial grade" wird keine ganz andere Elektronik haben können als eine standard-SD (abgesehen von dem SLC). D.h. sollte die Karte irgendwie gegen power down "besser" geschützt sein, muss das reine Softwarelösung in der Firmware sein. Auf eine micoSD passen nun mal keine Kondensatoren drauf. Egal ob industrial oder nicht. Und hier sind wir wieder bei dem Problem: man will es offenbar bei den Consumer SD nicht sauber lösen. Zumindest einige Hersteller pfuschen hier gewaltig.
soul e. schrieb: > Der RPi ist für Schul- und Ausbildungszwecke konzipiert, und damit vor > allem eins: billig. Man hat quasi das Beagleboard genommen und alles > weggelassen was nicht überlebensnotwendig ist. Das die Dinger mal als > Steuerungsrechner 24/7 durchlaufen hat sich seinerzeit keiner vorstellen > können. nun das sehe ich ein wenig anders: Es gibt mittlerweile RPIs im Modulargehäuse für die DIN rail, wenn das für Schul&Lehrzwecke gedacht ist, dann muss es schon eine besondere Schule sein ;)
Piter K. schrieb: > Wenn SD Karten so problematisch sind, sehe ich den schwarzen Peter bei > RPI foundation. Dass es bei Stromausfall die SD Karte zerschießen kann (Dateisystem) ist ein Dauerthema. Workarounds sind * RO SD Card zum Booten und ein "sicheres" Medium für den laufenden Betrieb. * Oder "einfach" sicherstellen, dass es nicht zum Stromausfall kommt. * Es scheint auch Karten zu geben, die prinzipiell zuverlässiger sind (wurde hier mal thematisiert, ich meine keine Industriekarten). Die Foundation hat sich imho wegen der Kosten für die SD Card entschlossen. Und der Preis ist ja einer der Gründe, warum der Pi so attraktiv ist. > das willst Du mir doch nicht wirklich weiß machen, > daß die SD Karte auf ein bestimmtes Layout und Lage der Partition > "optimiert" ist.... Wurde im Forum schon Mal behauptet. Kann mich aber nicht daran erinnern, dass es eine belastbare Quelle gab. > Wie man es wendet und dreht: ein Medium das jederzeit rauswurfbereit > ist, DARF dabei NICHT permanent zerstört werden. Bei den meisten Geräten Sehe ich ähnlich. Grundsätzlich würde ich das für einen Einzelfall halten. Mal schauen ob sich der Lothar noch mal meldet mit etwas mehr Backgroundinfos. BTW: Ich betreibe mehrere Pi-0 und 2 denen ich "häufig" den Strom kappe. Hatte bisher nicht mal Dateisystemfehler (Aldi SD Karten / "EMTEC").
Piter K. schrieb: > Übersetzung: "ist halt so und wir können es nur umtauschen, ansonsten > bitte zu industrial grade SD Karte greifen". Nun jetzt weiß ich, was ich > von dieser Firma halten soll. Immerhin geben sie unumwunden die Grenzen ihres Produktes zu und schieben es nicht auf einen seltenen unerklärlichen Einzelfall oder vermuteten Benutzerfehler, wie es bei anderen Firmen Standard ist.
soul e. schrieb: > Wear levelling unsterstellt einen bestimmten use case. Und der war zu > Beginn der SD-Ära sequenzielles Vollschreiben und anschließende > Komplettlöschung -- halt das was eine typische Kamera macht. Auf > wahlfreien Schreibzugriff waren früher nur die Industrie-Serien > ausgelegt. Gibt es Belege für deine Behauptung (wear levelling - use case)?
soul e. schrieb: > Neben den Daten werden im Flash auch Verwaltungsinformationen > gespeichert. Welche Blöcke sind kaputt, mit welchem Namen und welcher > Kapazität meldet man sich am Bus, teilweise sind da sogar Teile der > Controller-FW abgelegt. Wenn Du die durch einen Schreibunfall zerstörst, > brauchst Du das Herstellertool um die Karte neu zu konfigurieren. Flash wird blockweise gelöscht und beschrieben. Die Blockgröße ist je nach Flash unterschiedlich, liegt aber irgendwo zwischen paar kb und 256kb. Jetzt erklär mir bitte, wie soll die Firmware / Verwaltungsinformationen kaputt gehen, wenn diese sagen wir in den Blöcken 0,1,2,3 gespeichert sind und die User Daten (vom OS zugänglich) erst ab Block 5 anfangen? Selbst wenn der Controller ab und zu die Informationen updaten muss, würde jeder vernünftig denkender Mensch eine Lösung wählen, die erst neue Version der Daten schreibt, bevor die alte Version als ungültig verworfen wird. Als double buffering z.b. flashptr = area==0? block[1] : block[2] area = (area+1)%2 save_data_to_flash(flashptr) save_area_to_eeprom(area) usw... (als pseudocode) Selbst so ein µC auf einer microSD wird noch paar EEPROM zellen haben, wo man nicht gleich die Daten verliert und wo man die Daten für den double buffering algorithmus speichern kann. Wie gesagt, alles nur schlecht programmiert.
Piter K. schrieb: > Betrieb in RPI bedeutet nun mal KEIN FAT/VFAT voraus. FAT gibt's nur für > die /boot partition, der Rest ist ext4. Exakt. Kannst Du hier bitte die schriftliche Zusage von Kingston hochladen, in der Dir explizit zugesagt wurde, dass ein anderes als das vorformatierte FAT-basierte Dateisystem verwendet werden könne, ohne dass dabei Qualitätsprobleme auftreten? Vermutlich erliegst Du dem Irrglauben, dass die Aussage "preformatted with FAT<whatever>" so viel bedeutet wie: "Oh, das ist aber nett vom Hersteller, dass die Karte schon vorformatiert ist.". Stattdessen bedeutet sie eher: "Verändere bloß nicht die Vorformatierung, ansonsten gibt es Qualitätsprobleme!". > Wenn SD Karten so problematisch sind, sehe ich den schwarzen Peter bei > RPI foundation. Kannst Du hier bitte die schriftliche Zusage der RPi Foundation hochladen, in der Dir explizit zugesagt wird, dass exakt Dein Speicherkartentyp ohne Qualitätseinbußen unterstützt wird? Nein? > Und ein Wear leveling das nur bei bestimmten FS funktioniert halte ich > für ein Gerücht. Wäre wieder ein Fall von bad engineering. Es ist aber so. Ich habe (natürlich nach Unterzeichnung des entsprechenden NDA durch meinen Kunden) die von mir erwähnten Listen über die unterstützten und getesteten Dateisystemtypen höchstpersönlich nicht nur gelesen, sondern einen ausgiebigen Schriftverkehr mit dem zuständigen Applikationsingenieur des Kartenherstellers geführt. Für die konkrete Applikation wäre es darauf hinausgelaufen, zusammen mit dem Hersteller entsprechende Regressionstests durchzuführen und im Zweifelsfall ggf. die Kartenfirmware anzupassen. Hierbei ging es aber natürlich nicht um den üblichen Consumerschrott. Die betreffenden Speicherkarten sind übrigens auch auf dem "normalen Markt" für Industrieprodukte erhältlich. > Wenn ich mir > ein FAT filesystem nicht ab sektor 2048 sondern sagen wir 4096 anlege, ... trickst Du dabei ggf. das Wear Leveling der Kartenfirmware aus. > Wie man es wendet und dreht: ein Medium das jederzeit rauswurfbereit > ist, DARF dabei NICHT permanent zerstört werden. Das ist Deine Rechtsauffassung. Ohne entsprechende Evaluierungen sichert Dir das aber kein Hersteller zu. > Bei den meisten Geräten > sind SD Slots nicht geschützt, bzw die Karte schaut teilweise heraus. Na und? Irgendwo im Anhang des Kleingedruckten ab Seite 3455 der Anleitung des Geräts wird dann auch stehen, dass man die Karte bei eingeschaltetem Gerät tunlichst nicht hineinstecken oder herausziehen darf. > Und ich bin mir sicher, daß das mit sehr wenig Aufwand in der Firmware > sichergestellt werden kann. Flash geht nicht physikalisch kaputt bei > brownout. Es kann der Fall eintreten, dass ein Speicherblock unvollständig gelöscht wird. Dann sind zwar auf den ersten Blick alle Bits korrekt auf den Defaultwert gesetzt, aber es können noch Restladungen in den Speicherzellen vorliegen, die über den gesamten Parameterraum (Exemplarstreuungen, Temperatur, Versorgungsspannung, Mondphase, usw.) zu vereinzelten Bitfehlern führen. Bei SLC Flash ist die Gefahr noch überschaubar, aber bei MLC, TLC usw. steigt die Wahrscheinlichkeit solcher Bitfehler immens an. Man kann zwar im Dateisystem solche Dinge berücksichtigen, z.B. indem man nachvollzieht, welches der letzte gelöschte Speicherblock gewesen sein muss, um ihn auf Verdacht noch einmal zu löschen. Sämtliche FAT-Varianten sind hierfür aber ungeeignet, ebenso ext2/3/4. Die Kartenfirmware muss aber mit genau solchen flashuntauglichen Dateisystemen zurechtkommen. Da bei Vergleichstest in "Fach"zeitschriften oder Onlinemagazinen usw. primär auf die Schreib- und Lesegeschwindigkeiten geschaut wird, müssen die Hersteller da ggf. etwas sorglos agieren. Wer da auf Platz 3 landet, hat schon verloren und kann sein Produkt nur noch über den Preis verkaufen.
Mikro 7. schrieb: > Piter K. schrieb: >> Wenn SD Karten so problematisch sind, sehe ich den schwarzen Peter bei >> RPI foundation. > > Dass es bei Stromausfall die SD Karte zerschießen kann (Dateisystem) ist > ein Dauerthema. > Yep, und damit wäre ich ja glücklich... Karte raus, neu formatieren, backup drauf und gut ist. Aber in meinem Fall ist ja die Karte selbst mausetot. Nix mehr mit neu formatieren. Und es war ja nicht mal ein echter power down sondern nur ein reboot auf der Konsole - eventuell hat die SD Karte dann mittendrinn eine Resetflanke bekommen... wobei wenn ich mir auf die Schnelle das SD interface google: http://hades.mech.northwestern.edu/images/thumb/0/08/SD_Circuit.JPG/400px-SD_Circuit.JPG ist nicht mal ein Reset pin dabei (vielleicht eine Kombination aus diversen Pins?) !!! Und so was geht nun mal gar nicht !!! Wenn die Karte ihre Firmware verliert => Programmierung/Hersteller MIST. Wenn die Karte Verwaltungsdaten verliert => sollte zumindest in irgend einen Recovery Mode übergehen, der einen factory reset erlaubt (danach Karte leer aber wieder bespielbar), ansonsten MIST! Wenn Flash sektoren kaputt => sollte es als bad blocks melden, ansonsten MIST. Und wie gesagt, der Controller hat wirklich NIX dort herum zu flashen, wo seine Firmware sitzt.
Piter K. schrieb: > soul e. schrieb: > >> Der RPi ist für Schul- und Ausbildungszwecke konzipiert, und damit vor >> allem eins: billig. Man hat quasi das Beagleboard genommen und alles >> weggelassen was nicht überlebensnotwendig ist. Das die Dinger mal als >> Steuerungsrechner 24/7 durchlaufen hat sich seinerzeit keiner vorstellen >> können. > > nun das sehe ich ein wenig anders: Es gibt mittlerweile RPIs im > Modulargehäuse für die DIN rail, wenn das für Schul&Lehrzwecke gedacht > ist, dann muss es schon eine besondere Schule sein ;) Und Du meinst ernsthaft, dass ein Billidesign robuster wird, wenn man es in das Gehäuse eines Drittanbieters steckt? Die Modulargehäuse kamen auf den Markt nachdem die Leute anfinden, den RPi für Steuerungsaufgaben zu nutzen. Nicht umgekehrt. Baldrian schrieb: > soul e. schrieb: > >> Wear levelling unsterstellt einen bestimmten use case. Und der war zu >> Beginn der SD-Ära sequenzielles Vollschreiben und anschließende >> Komplettlöschung -- halt das was eine typische Kamera macht. Auf >> wahlfreien Schreibzugriff waren früher nur die Industrie-Serien >> ausgelegt. > > Gibt es Belege für deine Behauptung (wear levelling - use case)? Lies das Datenblatt Deiner Karte. Die meisten Hersteller liefern auch Applikationshinweise zum wear levelling. Allerdings fast immer gegen NDA -- Du musst also unterschreiben dass Du die Dokumente nicht weitergibst. Piter K. schrieb: > Selbst wenn der Controller ab und zu die Informationen updaten muss, > würde jeder vernünftig denkender Mensch eine Lösung wählen, die erst > neue Version der Daten schreibt, bevor die alte Version als ungültig > verworfen wird. Du unterstellst, dass auch bei billigsten Consumerprodukte Leute am Werk sind, die mit der modernsten Algorithmik das Maximum an Performance und Lebensdauer herausholen wollen. In der Praxis wird eher irgend ein alter Code übersetzt, angepasst bis das Ding durch die Tests rutscht, und dann ausgeliefert. > Wie gesagt, alles nur schlecht programmiert. Exakt.
Andreas S. schrieb: > Piter K. schrieb: >> Und ein Wear leveling das nur bei bestimmten FS funktioniert halte ich >> für ein Gerücht. Wäre wieder ein Fall von bad engineering. > > Es ist aber so. Ich habe (natürlich nach Unterzeichnung des > entsprechenden NDA durch meinen Kunden) die von mir erwähnten Listen > über die unterstützten und getesteten Dateisystemtypen höchstpersönlich > nicht nur gelesen, sondern einen ausgiebigen Schriftverkehr mit dem > zuständigen Applikationsingenieur des Kartenherstellers geführt. Für die > konkrete Applikation wäre es darauf hinausgelaufen, zusammen mit dem > Hersteller entsprechende Regressionstests durchzuführen und im > Zweifelsfall ggf. die Kartenfirmware anzupassen. Hierbei ging es aber > natürlich nicht um den üblichen Consumerschrott. Die betreffenden > Speicherkarten sind übrigens auch auf dem "normalen Markt" für > Industrieprodukte erhältlich. Glaube ich nicht. >> Wenn ich mir >> ein FAT filesystem nicht ab sektor 2048 sondern sagen wir 4096 anlege, > > ... trickst Du dabei ggf. das Wear Leveling der Kartenfirmware aus. Glaube ich überhaupt nicht. Belastbare Links, Quellen & Informationen müssen her. Geschichten mit NDA u. ä. helfen nicht weiter.
Andreas S. schrieb: > Es kann der Fall eintreten, dass ein Speicherblock unvollständig > gelöscht wird. Dann sind zwar auf den ersten Blick alle Bits korrekt auf > den Defaultwert gesetzt, aber es können noch Restladungen in den > Speicherzellen vorliegen, die über den gesamten Parameterraum > (Exemplarstreuungen, Temperatur, Versorgungsspannung, Mondphase, usw.) > zu vereinzelten Bitfehlern führen. Super....aussage. Wie wäre es: Flashblock löschen, neuen Inhalt schreiben und hinten dran die Checksum anhängen, dann Block auslesen, Checksum bilden und mit der gelesenen vergleichen.... zu schwer? wenn der Flash sagen wir mit 256kb blöcken arbeitet, kann man doch locker einen 512 byte "sektor" in jedem 256kb Block "opfern" um dort die Checksum zu speichern, das wären nicht mal 0.2% Kapazitätsverlust.
Baldrian schrieb: > Glaube ich nicht. > >>> Wenn ich mir >>> ein FAT filesystem nicht ab sektor 2048 sondern sagen wir 4096 anlege, >> >> ... trickst Du dabei ggf. das Wear Leveling der Kartenfirmware aus. > > Glaube ich überhaupt nicht. > > Belastbare Links, Quellen & Informationen müssen her. Geschichten mit > NDA u. ä. helfen nicht weiter. ich auch nicht... ließe sich zumindest prüfen, indem man unterschiedlich formatierte Karten beschreiben läßt, um zu sehen ob eine früher den Geist aufgibt (wenngleich nicht statistisch signifikant ;)
Bei einer geschätzten mittleren Produktlebensdauer von 30 Tagen pro FW-Version auch ein ziemlich sinnloses Unterfangen.
batman schrieb: > Bei einer geschätzten mittleren Produktlebensdauer von 30 Tagen pro > FW-Version auch ein ziemlich sinnloses Unterfangen. Wieder mal eine Behauptung. Selbst wenn es so wäre, die Firmware wird nicht in ASM geschrieben sein. Und die Flash bank wird auch so ähnlich aussehen, bei 99% der SD Karten. Mehr als eine Anpassung von ein paar Konstanten im C code ist das nicht (Flashgröße, Organization, Lage der reservierten Blöcke, Timing, überschaubar). Und entweder programmiert man so was sauber, dann läuft die FW rund egal welche Karte(ngröße/typ), oder man frickelt nur was zusammen, dann läuft es nicht rund, egal welche Karte. Es wird nicht alle 30 Tage vom Scratch entwickelt. SD Karten gibt es seit wie vielen Jahren, hm?
Ich fasse das bisherige zusammen: Kingston MicroSD Karten sind unter den Vorgaben aus der BWL-Abteilung entwickelt worden ;)
Hier noch was direkt von Kingston: https://media.kingston.com/pdfs/MKF_283.1_Flash_Memory_Guide_US.pdf Auszüge: ---------------- 2.0 SSD, Flash Card and USB Flash Drive Capacity Some of a Flash storage device’s listed capacity is used for formatting and other functions and thus is not available for data storage. When a Flash storage device is designed and manufactured, steps are taken to ensure that the device operates reliably and to permit the host device (computer, digital camera, tablets, mobile phone, etc.) to access the memory cells — i.e., to store and retrieve data on the Flash storage device. Formatting includes the following operations: 1 sh Memory Guide 1. Testing each memory cell in the Flash storage device. 2. Identifying all defective cells and taking steps to ensure that no data will be written to or read from a defective cell. 3. Reserving some cells to serve as “spares.” Flash memory cells have a long but finite lifetime. Therefore, some cells are held in reserve to replace any memory cells that may fail over time. 4. Creating a File Allocation Table (FAT) or other directory. To enable Flash devices to conveniently store and access customer files, a file management system must be created to allow any device or computer to identify the files stored in the Flash storage device. The most common type of file management system for Flash storage devices is the File Allocation Table (FAT), which is also used on hard drives. 5. Reserving some cells for use by the Flash storage device’s controller, e.g., for storing firmware updates and other controller-specific information. 6. Where applicable, reserving some cells for special features. For example, the specification for Secure Digital (SD) cards requires reserved areas to support special copy protection and security features. -------------- => es wird nicht behauptet FAT ist irgendwie obligatorisch.... -------------- • For Multi-Level Cell (MLC) Flash, up to 3000 write cycles per physical sector based on current lithography process (19nm and 20nm) at the time of this writing. For Single-Level Cell (SLC) Flash, up to 30,000 write cycles per physical sector. For Triple-level Cell (TLC), up to 500 write cycles per physical sector. Lithography of the Flash Memory Die plays a key role in cell endurance and decreases as the size of the die gets smaller. -------------- => da war meine Karte um Längen drunter... vielleicht wurden 16GB an writes erreicht auf der Karte (mit 16GB gesamt), aber auch nicht viel mehr. Die TBW wird doch kaum 16GB sein. -------------- Plug-and-Play Support: Kingston’s Flash memory line supports plug and play. With plug-and-play technology and compatible computer operating systems, a Flash storage device can be inserted into a computer or a Flash media reader and be quickly recognized and accessed by the computer. Hot-Swapping Support:Hot-swapping allows for plugging or unplugging Flash storage devices into a compatible computer or reader without needing to power off and restart the computer. This feature enhances the portability and convenience of Flash storage devices for transferring data, pictures or music between two computers or devices. -------------- Flash memory line meint auch SD Karten... also was nun? Mehr als "unmounten" kann ich eine Flashkarte sowieso nicht. Wo ist der Unterschied zu einem soft reboot?
Piter K. schrieb: > Es wird nicht alle 30 Tage vom Scratch entwickelt. SD Karten gibt es > seit wie vielen Jahren, hm? Jedenfalls nicht so lange wie Autos und trotzdem sind die nicht alle gleich. Manche taugen, andere weniger.
Bei einem anderen PI läuft eine EVO schon seit einem Jahr und der rebootet täglich über cron... und noch nichts ausgefallen.
Beitrag #5076222 wurde von einem Moderator gelöscht.
Noch ein Hinweis, wieso ein wear leveling speziell für FAT quatsch ist: selbst bei FAT kann ich doch auf jede beliebige Stelle X wie ein blöder schreiben, was macht der Controller dann? "Hey du darfst nur auf die Hauptdirectoryeinträge und den MBR schreiben, sonst bin ich weg" - oder was? Es ist eine Wahnvorstellung, daß mein ein wear leveling speziell für ein Filesystem entwerfen kann. JEDER controller wird einfach Blöcke, die sich nicht mehr fehlerfrei beschreiben lassen bzw zu oft beschrieben wurden "umverteilen", egal welcher block das nun ist.
Andreas S. schrieb: > Die meisten Controller gehen von FAT-Varianten aus und > betreiben dann z.B. bei ext2/3/4 gar kein Wear Leveling. Das wäre dann extrem blöd. Aber es gibt AFAIK verschiedene Controller Typen für SD Karten. Leider sieht man einer Karte den Controller nicht an, nichtmal über die SD Schnittstelle. Piter K. schrieb: > Die Blockgröße ist je > nach Flash unterschiedlich, liegt aber irgendwo zwischen paar kb und > 256kb. LOL: Bei SDHC sind das 4 MByte pro Block laut öffentlicher Spec. Piter K. schrieb: > writes erreicht auf der Karte (mit 16GB gesamt), aber auch nicht viel > mehr. Die TBW wird doch kaum 16GB sein. Problem: Durch die großen 4MB Blöcke kann sich die interne TBW vervielfachen, wenn für einen 4K Block im Dateisystem gleich ein 4M Block im Flash neu geschieben wird. Zum Bleistift weil sich die A-Time einer Datei geändert hat- oder falls SWAP eingerichtet wurde. Und ja, da sind normalerweise hochwertige Fehlerkorrektur Algorithmen drin in so einer µSDHC. Leider aber auch ungetesteter Flash Speicher - getesteter Flash ist in aller Regel deutlich teurer als eine gleich große SD Karte, und bei letzterer ist ja noch ein Controller Chip mit drin. Piter K. schrieb: > Wenn die Karte Verwaltungsdaten verliert => sollte zumindest in irgend > einen Recovery Mode übergehen Kann sie nicht IMHO. Der Controller Chip hat ohne die Daten keine Idee was für Flash denn überhaupt so angeschlossen ist - die Dinger sind generisch für viele Typen. Und für den Recovery Mode bräuchte man genau die Tools für die sich auch die ollen Fälscher (2TB µSD!!!1einself) brennend interessieren...
Piter K. schrieb: > Eigentlich dachte ich ein Prämium-Produkt zu kaufen... so war bislang > meine Meinung von Kingston. Und billig war's wirklich nicht. Hohe Preise locken natürlich auch die Fälscher an... Ich teste daher jedes neue Speichermedium, egal ob SdKarte, oder USB-Stick, oder Laufwerk erst einmal mit dem h2testw von Heise. Bei großen Datenträgern dauert das auch mal ein Weilchen länger, aber danach weiß ich, ob der ausgewiesene Speicher physisch auch wirklich vorhanden ist. Alllerdings sind auch mir schon ein oder zwei Karten am Raspi gestorben, ohne dass ich mir einer Schuld bewusst bin. Das ist zwar ärgerlich, aber das Zeug ist einfach zu billig um tagelange Ursachenforschung oder Wiederbelebungsversuche zu machen.
Jim M. schrieb: > LOL: Bei SDHC sind das 4 MByte pro Block laut öffentlicher Spec. nach außen vielleicht - sagt aber nichts über die mögliche erase size auf dem internen Die aus.
Übrigens den hier angepriesenen SD Card Formatter habe ich in einer freien Minute ausprobiert.... Ergebnis wie erwartet: Das Programm zeigt kurz eine 239.75MB Karte an und hängt sich auf... Was man noch versuchen könnte wäre direkt die PINs anzusprechen, mit Umgehung des Controllers. Vielleicht kann man so wenigstens einen Fehlercode auslesen? Habe aber gerade kaum Zeit für so was und auch keine Software zur Hand (ein Arduino müßte es mit dem richtigen Sketch können).
H. E. schrieb: > Walter Tarpan schrieb: >> H. E. schrieb: >>> Seit dem habe ich ein "Power-Management" gelötet. Ein einziger Taster >>> zum runterfahren und wieder hochfahren. >>> >>> Wenn jemand an der Lösung interessiert ist, poste ich sie gerne. >>> Schaltplan, Ursprungsforumspost, Bilder von meiner Lösung. >> >> Mich interessiert die Lösung. Ich hatte damals mal etwas derartiges >> gemacht - nur seitdem sich mit einem neuen Kernel die Pin-Steuerung aus >> dem Userspace entfernt hatte, habe ich es nicht mehr hinbekommen. >> >> Viele Grüße >> W.T. > > Habe dafür ein Topic eröffnet. > Beitrag "PI3, Interes WakeUp, PowerManagement mit nur einem Taster" :) Nun, nochmal zum Thema Lösung des Problems: wie wäre es mit einer LV Shottky Diode(*) im VDD path des SD slots und danach ein kleiner Cap? (klein naja relativ...). Habe mir den RPI3 layout noch nicht angeschaut aber vielleicht kann man das relativ schmerzlos hinbekommen? Ansonsten könnte vielleicht jemand einen Adapter erfinden, den man in den SD slot steckt, auf dem eine kleine backup-Versorgung (1000µ 3.3V) steckt und der Slot auf der anderen Seite durchgereicht (bis auf VDD) herauskommt? Wäre kaum größer als 2x MicroSD, kann mir nicht vorstellen, daß das zu ernsthaften Timingproblemen führt. (*) ersetzen durch was auch immer besser ist.
So mal als ASCII Art:
1 | ------------------- |
2 | ------/ | = | |
3 | |= | = | <--- Karte hier |
4 | |= STECKER |SLOT = | |
5 | |= | | |
6 | -------------|------------ |
7 | | CAP | D | |
8 | ------------ |
9 | <------------> |
10 | verschwindet |
11 | im RPI |
Also man kann ja jetzt weiter darauf herumreiten wie schlimm das alles ist mit dem Design von SD-Karten oder auch dem Pi, aber im Allgemeinen gehen halt Flash-Speicher je nach Qualität ab und zu mal kaputt. Wer sagt denn, dass diese Karte jetzt genau aus dem hier vermuteten Grund und nicht einfach nur so kaputt gegangen ist? Könnte doch auch sein, oder? Bisher hat nur Lothar sich mit seinen Erkenntnissen aus eigenen Tests zu Wort gemeldet. Alles andere waren nur singuläre eigene Erfahrungen die selbstverständlich als negativ empfunden und so kommuniziert werden. Aber wer kann beweisen, dass seine Karte ausgefallen ist weil der Flash-Controller wegen Stromausfall oder Ähnlichem die Hufe hoch gerissen hat und es nicht einfach die normale Sterblichkeitswahrscheinlichkeit war?
@Peter: nun, die Stellungnahme von Kingston spricht eigentlich für ein generelles Problem. Eventuell ein understatement, man tauscht lieber aus, als sich mit den Ursachen zu beschäftigen? Als User stellt sich mir dann aber die Frage, was mache ich, um nicht alle paar Wochen eine microSd kaufen zu müssen? Wenn ich gerade auf dem PI was deven muss... ich habe schon Schiss das Ding zu rebooten :/ Das kann's doch nicht sein.
Mikro 7. schrieb: >> oder die Karte gar nicht mehr erkannt wird. > Das wäre eine neue Dimension. Wie identifzierst du das? Ungültiges SPI > Packet, Error Response, Initialisierung, ... ? Ich stecke sie an verschiedene Geräte und schaue, was die damit anfangen. Wenn z.B. ein Windows Rechner nichts mehr mit der Karte anfangen kann und nichtmal das SMART Tool des Herstellers auf die Karte kommt, dann ist das Ding für mich defekt. Peter schrieb: > Bisher hat nur Lothar sich mit seinen Erkenntnissen aus eigenen Tests zu > Wort gemeldet. Diese Tests umfassen ca. 70 Karten mehrerer Hersteller. Die untauglichen Karten sind nach 1-2 Wochen defekt. Die Besten halten über 40 Wochen. Bei diesen verläuft der Test natürlich eher "zäh"... ? Peter schrieb: > Aber wer kann beweisen, dass seine Karte ausgefallen ist weil der > Flash-Controller wegen Stromausfall oder Ähnlichem die Hufe hoch > gerissen hat und es nicht einfach die normale > Sterblichkeitswahrscheinlichkeit war? Wer schlechte Karten hat, bekommt das problemlos hin. Ich habe diese langjährigen Tests nur deshalb begonnen, weil aus der "Prototypserie" mit TLC Flash Fehler gemeldet wurden. Und das schon wenige Wochen nach Auslieferung der ersten Maschinen. Und zum Glück habe ich dann mit Samsung recht gute Consumer-Karten gefunden, und bin jetzt mit den Glyn MLC Karten sehr zufrieden. Kingston waren wegen des "guten Namens" übrigens die zweiten, die ich ausprobiert habe. Der Test war recht kurz... Piter K. schrieb: > Shottky Walter hieß Schottky.
:
Bearbeitet durch Moderator
Piter K. schrieb: > => es wird nicht behauptet FAT ist irgendwie obligatorisch.... Das gibt der SD-Standard vor. In dem steht, daß SD-Karten mit FAT16, SDHC-Karten mit FAT32 und SDXC-Karten mit exFAT zu formatieren sind. Letztlich ist die Designentscheidung, im Raspberry Pi eine SD-Karte als Systemlaufwerk zu verwenden, nicht die schickste gewesen, aber das SOC ist halt so ... bescheiden, daß ein sinnvoller Betrieb mit was anderem nicht ohne weiteres möglich ist. Und nun ist es auch so, daß nicht jeder, der einen Raspberry Pi verwendet, damit automatisch seine SD-Karten schrottet, das scheint also schon auch irgendwie vom Nutzungsprofil abzuhängen.
Man sollte regelmäßig ein Backup machen. Das geht so: https://www.raspberrypi.org/forums/viewtopic.php?f=91&t=46911 Ich selber verwende 32G Sandisk und hatte noch keine Ausfälle trotz intensiver Benutzung.
Peter schrieb: > Aber wer kann beweisen, dass seine Karte ausgefallen ist weil der > Flash-Controller wegen Stromausfall oder Ähnlichem die Hufe hoch > gerissen hat und es nicht einfach die normale > Sterblichkeitswahrscheinlichkeit war? Das lustige an der Sache ist übrigens, dass es gar nicht sooooo arg viele Flash-Hersteller gibt. Und deshalb mit hoher Wahrscheinlichkeit in gleichzeitig am Markt verfügbaren Karten das (annähernd) selbe Flash verbaut ist. Ob eine Karte also 2 oder 40 Wochen durchhält, liegt dann sehr stark in der Firmware und im Wearleveling. Und genau so habe ich das beobachtet: microSD eines Herstellers X mit der Firmware A waren nach 2..3 Wochen kaputt. Nach Analyse durch den Hersteller X (das hat mich beeindruckt, Hersteller K z.B. ließ nur von sich hören, die Karten seien eben defekt) stellte der den Algorithmus um und die (selben!!) Karten laufen jetzt ein dreiviertel Jahr ohne Probleme. Und so ist es lustigerweise auch bei den anderen Karten: ein Hersteller verwendet "sein" Firmwarekonzept für alle seine Karten. Und deshalb ist es für mich wenig überraschend, dass alle 4 unterschiedlichen von mir getesteten Samsung-Karten sehr gute Ergebnisse liefern. Und 3 unterschiedliche Kingston-Karten eben eher schlechte... J. W. schrieb: > Ich selber verwende 32G Sandisk und hatte noch keine Ausfälle trotz > intensiver Benutzung. Ich kann zu einer (relativ teuren) SDSDQM-008G nur sagen, dass sie eine der schlechtesten im Test war. Weitere Karten von Sandisk habe ich dann gleich gar nicht getestet...
:
Bearbeitet durch Moderator
Rufus Τ. F. schrieb: > Letztlich ist die Designentscheidung, im Raspberry Pi eine SD-Karte als > Systemlaufwerk zu verwenden, nicht die schickste gewesen, aber das SOC Nicht die "schickste"? ;-) SD Card ist billiger als Flash (bei vergleichbarer Größe) und auch einfacher zu handhaben für die "Zielgruppe" des Pi. Das gilt es gegen die geringerer Ausfallsicherheit abzuwägen. > ist halt so ... bescheiden, daß ein sinnvoller Betrieb mit was anderem > nicht ohne weiteres möglich ist. Was meinst du mit "nicht ohne weiteres"? Dass eMMC auf dem Pi problemlos (?) möglich ist, sieht man am (none-lite) CM3.
Lothar M. schrieb: > Und genau so habe ich das beobachtet: microSD eines Herstellers X mit > der Firmware A waren nach 2..3 Wochen kaputt. Nach Analyse durch den Hast du eine Möglichkeit gefunden, die guten von den schlechten Karten (vorweg) zu identifizieren? (Ich habe nicht den Überblick was die SD Schnittstelle an Daten hergibt woran man sowas festmachen könnte.)
Lothar M. schrieb: > Das lustige an der Sache ist übrigens, dass es gar nicht sooooo arg > viele Flash-Hersteller gibt. Und deshalb mit hoher Wahrscheinlichkeit in > gleichzeitig am Markt verfügbaren Karten das (annähernd) selbe Flash > verbaut ist. Ob eine Karte also 2 oder 40 Wochen durchhält, liegt dann > sehr stark in der Firmware und im Wearleveling. Und an der Selektion. Wie Kartoffeln werden auch NAND-Flashbausteine in Güteklassen unterteilt. Die guten nutzt man für SSDs, die akzeptabeln für Speicherkarten mit hoher Kapazität, und der Schrott kommt in Pendrives/Memorysticks und Consumer-SD. Da hast Du dann schonmal 150 GB unformatierte Kapazität in einer 64 GB-Karte. Die kaputten Blöcke sind ausgeblendet und für den User nicht sichtbar. > Und so ist es lustigerweise auch bei den anderen Karten: ein Hersteller > verwendet "sein" Firmwarekonzept für alle seine Karten. Softwareentwicklung kostet Geld. Wird gerne vergessen, da man sich ja alles irgendwo runterladen kann, aber letztendlich ist die Entwicklung und Optimierung der Algorithmen ein Kostenfaktor. Daher laufen gerade preissensitive Produkte oft mit ziemlich suboptimaler Firmware.
Mikro 7. schrieb: > Dass eMMC auf dem Pi problemlos (?) möglich ist, sieht man am > (none-lite) CM3. Sind SD/MMC und eMMC nicht technisch das gleiche? Abgesehen von der Idee, dass eMMC vielleicht geringfügig robuster konstruiert ist, weil nicht als einfach austauschbar angesehen? soul e. schrieb: > Da hast Du dann schonmal 150 GB > unformatierte Kapazität in einer 64 GB-Karte. bunnie hatte wohl mal eine 128 MB-Karte analysiert, wo 16 GB Flash drin verbaut waren. Das geht also beliebig schlecht. Mir war bekannt, dass ein Stromausfall auf einer SD-Karte beliebige Blöcke zerstören kann, d.h. ein Journaling-Dateisystem ist auf solchen Karten vollständig wertlos. Eigentlich müsste man nach jedem hard-reset ein Backup einspielen, um keinen Datenverlust zu riskieren. Daher einen Dank an Lothar für seine Erfahrungen. Die Hotplug-Funktionalität hat mit dieser Problematik übrigens nichts zu tun, weil die Power-Pins einer (Micro)SD-Karte länger sind. Beim Herausnehmen wird die Karte also noch hinreichend lange versorgt, um nicht zu sterben.
Mikro 7. schrieb: > Hast du eine Möglichkeit gefunden, die guten von den schlechten Karten > (vorweg) zu identifizieren? Jein. Die ganz schlechten sind die Consumer-Karten, die kaum die Bilder vom letzten Urlaub behalten können... ;-) soul e. schrieb: > Da hast Du dann schonmal 150 GB unformatierte Kapazität in einer 64 > GB-Karte. Die kaputten Blöcke sind ausgeblendet und für den User nicht > sichtbar. Einer der "Tricks" zur "Langlebigkeit" ist der, in eine industrielle 8GB Karte ein billiges 32GB Flash zu bauen. Dann hat man sogar ohne ausgeschlafenes Wearleverling schon mal die vierfache "Lebensdauer"... S. R. schrieb: > Mir war bekannt, dass ein Stromausfall auf einer SD-Karte beliebige > Blöcke zerstören kann Ein anderer Test war, auf eine "volle" Karte in eine Logdatei laufend noch ein zusätzliches Byte zu kopieren, dann muss die Karte quasi laufend "umsortiert" werden. Die Karte war dauernd unter Strom und trotzdem waren nach gewisser Zeit (2 Mio ... 200 Mio Kopiervorgänge je nach Hersteller) Daten korrupt, die nie angefasst, sondern nur gelesen wurden. Solche korrupten Daten zeugten dann (gern auch zusammen mit einem "langsamer Werden") vom baldigen Ende der Karte.
:
Bearbeitet durch Moderator
Das bedeutet also insgesamt: man darf SD Karten niemals als sicheres Speichermedium ansehen. Für Fotos oder "wegwerfbares" RPi-OS oder Transfer von Powerpoints ok, aber Daten speichern und sich darauf verlassen in 100%iger Korrektheit und langfristiger Haltbarkeit kann man völlig vergessen. Gut zu wissen, dass hätte ich so bisher auch nicht gesehen. Auch wenn mir klar war, das eine SD keine Festplatte ist.
Conny G. schrieb: > Das bedeutet also insgesamt: > man darf SD Karten niemals als sicheres Speichermedium ansehen. Du müsstest du zuerst klären, was ein sicheres Speichermedium ist, bevor du dich zu so einer Aussage hinreißen lässt. Die meisten Aussagen in diesem Thread sind ohne Wert, da sie nicht belegt werden.
Conny G. schrieb: > Das bedeutet also insgesamt: > man darf SD Karten niemals als sicheres Speichermedium ansehen. Das gilt für jeden Typ von NAND-Flash. Selbst hochwertige SSD-Laufwerke garantieren Dir den Datenerhalt nur, wenn Du sie einmal im Jahr an Strom hängst und den Controller seine Zellenprüfung machen lässt. Steht aber auch alles in den Datenblättern. Für's Archiv sind Magnetfestplatten und -bänder immer noch die beste Wahl. Aber auch da ist regelmäßige Kontrolle angesagt.
Conny G. schrieb: > Gut zu wissen, dass hätte ich so bisher auch nicht gesehen. Auch wenn > mir klar war, das eine SD keine Festplatte ist. Jemand hat dazu mal sinngemäß gesagt: "Flash speichert nicht deine Daten, Flash speichert nur eine statistische Approximation deiner Daten." Gilt für billigen Flash sicher noch viel mehr - und SD-Karten sind so ziemlich das billigste Speichermedium, was man kriegen kann. Ich traue Flash nicht besonders. Andererseits geht der Trend in Rechenzentren zu reiner Flash-Bestückung, ganz ohne rotierende Medien...
soul e. schrieb: > Das gilt für jeden Typ von NAND-Flash. Das gilt sogar für NOR-Flash. > wenn Du sie einmal im Jahr an Strom hängst und den Controller seine > Zellenprüfung machen lässt. Da habe ich auch noch einen Test am Laufen: ich hatte mit 2 Karten einen Test begonnen, brauchte aber nach 1 Woche die Prüfplätze für andere Karten. Also die beiden Karten herausgenommen und sicher eingelagert. Die Unterbrechung dauerte knapp ein halbes Jahr. Dann wollte ich die beiden zwischengelagerten microSD weitertesten, und böse Überraschung: beide waren nicht mehr ansprechbar. Eine wurde gar nicht mehr erkannt, die andere meldete sich mit Hieroglyphen... S. R. schrieb: > Jemand hat dazu mal sinngemäß gesagt: "Flash speichert nicht deine > Daten, Flash speichert nur eine statistische Approximation deiner Daten." Ja, wenn pro Zelle 3 Bit gespeichert werden (= 8 verschiedene Zustände), dann ist das reinste Analogtechnik...
:
Bearbeitet durch Moderator
Die Adapter sind auch oft ein Problem. Der offizielle der bei einer Kingstiondisc dabei war (so ein fummeliges Minniteil) wird abartig heiss, Datenrate deutlich niedriger. Die gleiche Karte in einen 'grossen' Reader und siehe da die Rate ist gleich mal 10MB höher. Verreckt ist mir noch keine SD-Karte, dafür USB-Sticks. Was oft als Markenkarte verkauft wird sind auch oft Fälschungen. Da gabs irgendwo mal nen Test wo sie bei diversen Händlern originale Samsung,.. Karten kauften, war z.g.T. alles Fälschungen, ist ja bei Akkus das selbe. Was da drinn steckt weiss keiner und selbst wenn es Originale sind, die Chargen sind nie gleich, da wird dann schon mal bei hoher Nachfrage auch der Ausschuss verbaut, da wird nix weggeworfen. Da ging doch neulich auch eine Meldung durch die IT-PResse, als 'neue' SSDs mit Daten von Nutzern auftauchten weil recyclete Bausteine verwendet wurden. Das ist doch alles ein riesen Beschiss da nicht nachprüfbar für den Kunden und wo sich die Gelegenheit ergibt zu bescheissen, da wird auch beschissen, auch bei den "professionellen" Serien, weil dort noch mehr Geld zu holen ist.
> Und ein Wear leveling das nur bei bestimmten FS funktioniert halte > ich für ein Gerücht. Vor ein paar Jahren hatte diese Frage mal der Firma Sandisk gestellt. Ich bekam eine klare antwort, daß ich die Partitionstabellen und Filesysteme nicht ändern soll, weil sonst ordnungsgemäße Funktion nicht merh sicher ist. Konkret hatte ich nach VFAT, EXT3 und NTFS gefragt, die wurden alle als unsicher abgelehnt. Sicher ist das eine Weile her, aber es wäre trotzdem sicher unklug davon auszugehen, daß heute alle Karten alle Filesysteme unterstützen. > man darf SD Karten niemals als sicheres Speichermedium ansehen. Für meine Foto Kamera hatte ich z.B. mal eine Speicherkarte von Sony gekauft, die wasserdicht ist und 5 Jahre Garantiert keinen Datenverlust. Die Karte hat allerdings nicht 9,95 Euro gekostet, sondern fast 50,00 Euro. Von Sony gab es im selben Laden auch Karten mit dem sonst üblichen Preis, die waren dann aber ohne Garantie gegen Datenverlust.
Stefan U. schrieb: > Vor ein paar Jahren hatte diese Frage mal der Firma Sandisk gestellt. > Ich bekam eine klare antwort, daß ich die Partitionstabellen und > Filesysteme nicht ändern soll, weil sonst ordnungsgemäße Funktion nicht > merh sicher ist. Daniel hat hier den Sandisk Support zur selben Frage angerufen, und eine Gegenteilige Antwort erhalten: Beitrag "Re: SDXC 128GB Karte richtig mit EXT4 formatieren"
Stefan U. schrieb: > Vor ein paar Jahren hatte diese Frage mal der Firma Sandisk gestellt. > Ich bekam eine klare antwort, daß ich die Partitionstabellen und > Filesysteme nicht ändern soll, weil sonst ordnungsgemäße Funktion nicht > merh sicher ist. Das kann auch einfach nur bedeuten, dass sie nur mit einem FS getestet haben (nämlich das was in der Spec steht) und man sich nicht zu weit aus dem Fenster lehnen will. Argumente was so alles schief gehen kann und warum wurden hier inzwischen zahlreiche genannt. Was fehlt, wie einer der Vorredner bereits sagte, sind belastbare Quellen. Auf Anhieb konnte ich zumindest die unten stehende Studie finden. Vielleicht habt ihr ja noch weitere Referenzen. https://www.usenix.org/conference/fast13/technical-sessions/presentation/zheng
Personalvorstand a.D. schrieb: > Die Adapter sind auch oft ein Problem. Der offizielle der bei einer > Kingstiondisc dabei war (so ein fummeliges Minniteil) wird abartig > heiss, Datenrate deutlich niedriger. Was meinst Du mit "Adapter"? Micro-SD-auf-SD? Der kann nicht heiß werden. Oder ist für Dich ein USB-Kartenleser ein Adapter?
Stefan U. schrieb: > Konkret hatte ich nach VFAT, EXT3 und NTFS gefragt, die wurden alle als > unsicher abgelehnt. Dann hatte der Antwortende keine Ahnung, denn VFAT ist die Werksformatierung (wenn man mal annimmt, dass Sandisk Windows im Blick hat). Ein "wird nicht unterstützt" ist aus Sicht der Firma die Top-Antwort, denn damit können sie sich komplett aus der Schlinge ziehen...
> Das kann auch einfach nur bedeuten, dass sie nur mit einem FS > getestet haben Ja sicher. Wie beim lesen Datenblättern sollte man sich besser an die zugesicherten Vorgaben des Herstellers halten - wenn man denn auf Zuverlässigkeit Wert legt. Alles andere wäre Ok, wenn man mit Glück schon zufrieden ist. Ich habe selten Glück. Was schief gehen kann, das geht auch schief.
Rufus Τ. F. schrieb: > Piter K. schrieb: >> => es wird nicht behauptet FAT ist irgendwie obligatorisch.... > > Das gibt der SD-Standard vor. In dem steht, daß SD-Karten mit FAT16, > SDHC-Karten mit FAT32 und SDXC-Karten mit exFAT zu formatieren sind. > das gibt es nicht vor, es wird nur empfohlen und zwar aus Effizienzgründen... FAT16 kann ab einer gewissen Größe nicht mehr sinnvoll arbeiten.
Personalvorstand a.D. schrieb: > Die Adapter sind auch oft ein Problem. Der offizielle der bei einer > Kingstiondisc dabei war (so ein fummeliges Minniteil) wird abartig heiss ACK, aber nur unter Windows, beim gleichen Rechner unter Linux blieb er kalt und war sogar schneller
S. R. schrieb: > Ein "wird nicht unterstützt" ist aus Sicht der Firma die Top-Antwort, > denn damit können sie sich komplett aus der Schlinge ziehen... Vor allem interessant wäre es zu wissen, welchen "Rang" der Support-Mitarbeiter hatte.... ich wette der hat in die Werbebroschüren geschaut bzw in Firmeninterne Supportseiten und da steht was von FAT drin. Und so folgte prompt die Antwort "bitte nur FAT", ohne jedoch überhaupt eine Ahnung zu haben was ein Filesystem ist. Leider ist das oft so beim Support. Wenn in den Supportseiten stehen würde bitte nur senkrecht einsetzen würde es dir dieser Mitarbeiter genauso besinnungslos zurück schreiben.
Piter K. schrieb: > Und so folgte prompt die Antwort "bitte nur FAT", ohne jedoch überhaupt > eine Ahnung zu haben was ein Filesystem ist Es ist durchaus so, dass die Firmware der Karten das Filesystem beachtet und bei verbreiteten FS das Wearleveling entsprechend anpasst. Oder gar Blöcke/Sektoren mehrfach abspeichert. Und da ist ein relativ starres und einfach zu interpretierndes FS natürlich von Vorteil.
Piter K. schrieb: >> Das gibt der SD-Standard vor. In dem steht, daß SD-Karten mit FAT16, >> SDHC-Karten mit FAT32 und SDXC-Karten mit exFAT zu formatieren sind. > das gibt es nicht vor, es wird nur empfohlen und zwar aus > Effizienzgründen... Nein, das Dateisystem ist im Standard festgeschrieben. Eine SDHC-Karte mit ext4 ist keine standardkonforme SDHC-Karte mehr.
S. R. schrieb: > Nein, das Dateisystem ist im Standard festgeschrieben. > Eine SDHC-Karte mit ext4 ist keine standardkonforme SDHC-Karte mehr. Referenz? Angabe von Quelle und Paragraph bitte.
Piter K. schrieb: > Referenz? Angabe von Quelle und Paragraph bitte. Langsam reicht es. Es gibt hier ein paar Leute, die mit den Interna der Entwicklung von Speichermedien bereits etwas intensiver in Kontakt gekommen sind als der normale Anwender. Diese Leute haben Dir schon einiges an Tips gegeben. Die entsprechenden Dokumente unterliegen NDAs und sind daher nicht öffentlich zugänglich. Wenn Du konsequent alles wegdiskutieren willt, Deine Sache. Dein Auto verbraucht auch exakt soviel Sprit, wie im Herstellerdatenblatt steht.
Lothar M. schrieb: > Es ist durchaus so, dass die Firmware der Karten das Filesystem beachtet > und bei verbreiteten FS das Wearleveling entsprechend anpasst. Oder gar > Blöcke/Sektoren mehrfach abspeichert. Und da ist ein relativ starres und > einfach zu interpretierndes FS natürlich von Vorteil. Anpasst AN WAS??? Dir ist klar wie ein Filesystem funktioniert? FAT hat starre STamm-Verzeichnisstruktur, mehr aber auch nicht. Der Host kann dann trotzdem auf der Karte wild herum schreiben, was hilft es dem Wearleveling zu vermuten, daß auf die stamm directories öfter geschrieben wird? Außerdem legt der FAT Format auch fest, daß eben diese directories an beliebigen Sektor anfangen können, dank reserved sectors: https://de.wikipedia.org/wiki/File_Allocation_Table
1 | Reservierte Sektoren |
2 | |
3 | Zwischen Bootsektor und der ersten FAT können Sektoren reserviert werden, die vom Dateisystem nicht benutzt werden. Dieser Bereich kann von einem Bootmanager oder für betriebssystemspezifische Erweiterungen genutzt werden. Auf den meisten FAT12- oder FAT16-Dateisystemen existieren – außer dem Bootsektor – keine weiteren reservierten Sektoren. Die FAT folgt somit direkt im Anschluss an den Bootsektor. FAT32-Dateisysteme enthalten in der Regel noch einige Erweiterungen zum Bootsektor sowie eine komplette Sicherungskopie des Bootsektors und der Erweiterungen. |
Also NIX mit starren Sektornummern.... jetzt wirst Du mir natürlich weiß machen wollen, daß der µC der SD Karte die partition table und sonstige FS Strukturen beim powerup auswertet und sich dementsprechend anpasst? Das sind Gute Nacht Märchen. Zeigt mir doch bitte den Source einer SDcard Firmware, wo eine lesende Implementierung von FAT eingebaut ist (und das müßte dann alle FAT Varianten abdecken).
soul e. schrieb: > Langsam reicht es. Es gibt hier ein paar Leute, die mit den Interna der > Entwicklung von Speichermedien bereits etwas intensiver in Kontakt > gekommen sind als der normale Anwender. Diese Leute haben Dir schon > einiges an Tips gegeben. Die entsprechenden Dokumente unterliegen NDAs > und sind daher nicht öffentlich zugänglich. joooo... so argumentieren kann ich auch... ich weiß alles besser, aber ich darf dir nicht sagen, wo es steht, ich habe alles mit eigenen Augen gesehen, aber man hat mir verboten, Fotos zu machen und auch sonst darf ich nichts darüber berichten. Absolute Schweigepflicht, ansonsten holen sie und buchten meine Familie ein. So in etwa argumentierst Du ;)
Piter K. schrieb: >> Nein, das Dateisystem ist im Standard festgeschrieben. >> Eine SDHC-Karte mit ext4 ist keine standardkonforme SDHC-Karte mehr. > > Referenz? Angabe von Quelle und Paragraph bitte. Für SD-Karten nennt Wikipedia als Quelle:
1 | SD Memory Card Specifications – PART 2 FILE SYSTEM SPECIFICATION – Version 1.0. 1.0. SD Group, Matsushita Electric Industrial Co., Ltd. (MEI), SanDisk Corporation, Toshiba Corporation. February 2000. |
Da kannst du selbst nachschlagen, ich kann es nicht. Die "Physical Layer Simplified Specification Ver6.00" nennt in 4.13.2.7.3:
1 | 4.13.2.7.3 Requirements of SD File System |
2 | |
3 | This specification can be applied only to the SD file system formatted card defined by the File System Specification Version 3.00. This includes complying with the format parameter calculation specified in the Appendix C of the File System Specification Version 3.00. |
4 | Furthermore, the Number of Hidden Sectors shall be adopted as minimum number that meets Boundary Unit Recommendation for Data Area. And in case of exFAT file system, Allocation Bitmap shall be stored in the first 4MB of Cluster Heap. |
Ferner wird dort detailliert auf die FAT-Updates eingegangen, und welche Zeiten dort wann und wo einzuhalten sind. Piter K. schrieb: > Absolute Schweigepflicht, ansonsten holen > sie und buchten meine Familie ein. Die Standards sind nicht öffentlich, ALSO GEH UND BESORG SIE DIR GEFÄLLIGST SELBST, wenn du nichts glaubst.
soul e. schrieb: > Die entsprechenden Dokumente unterliegen NDAs und sind daher nicht > öffentlich zugänglich. Du musst für Auskünfte auf der Messe den FAE oder einen, der der Entwicklung nahesteht in einer schwachen Minute erwischen. Auskünfte über Interna gibt es gar nicht. Nicht mal über NDA. Eine Frage, die ich schon Anfang des Jahrtausends bezüglich CF Karten gestellt habe, war einfach: Wie lange muss die Karte nach dem letzten Schreibbefehl noch mit Spannung versorgt werden, dass sie mit internen Verwaltungsaufgaben fertig ist und die Finger vom Flash lässt? Resultat nach monatelanger Fragerei: die Karten werden aufgemacht, ein paar Drähte ans Flash gelötet und der Logikanalyser angeschlossen. Und erst auf die Frage, was denn da knapp 700ms nach dem Schreibbefehl noch am Flash passiere, und ob diese Zeit noch schlimmer sein könnte, bekam ich die Antwort, dass die Karte noch für 1s gepuffert werden sollte.
:
Bearbeitet durch Moderator
Nachtrag: Du darfst den referenzierten Standard auch in Google eintragen, dort findest du dann ein vom LKW gefallenes "confidential document", wo die Bytes genau spezifiziert sind. Vielleicht glaubst du dem ja.
S. R. schrieb: >
1 | > 4.13.2.7.3 Requirements of SD File System |
2 | > |
3 | > This specification can be applied only to the SD file system formatted |
4 | > card defined by the File System Specification Version 3.00. This |
5 | > includes complying with the format parameter calculation specified in |
6 | > the Appendix C of the File System Specification Version 3.00. |
7 | > Furthermore, the Number of Hidden Sectors shall be adopted as minimum |
8 | > number that meets Boundary Unit Recommendation for Data Area. And in |
9 | > case of exFAT file system, Allocation Bitmap shall be stored in the |
10 | > first 4MB of Cluster Heap. |
11 | > |
CAN BE APPLIED ONLY TO... des Englischen mächtig? Eine SD Karte ohne FAT Filesystem ist immer noch eine SD Karte... > Die Standards sind nicht öffentlich, ALSO GEH UND BESORG SIE DIR > GEFÄLLIGST SELBST, wenn du nichts glaubst. werde ich versuchen.
Piter K. schrieb: > CAN BE APPLIED ONLY TO... > des Englischen mächtig? Es ist vollkommen egal, was man schreibt, du glaubst es ja doch nicht.
soul e. schrieb: > Wenn Du konsequent alles wegdiskutieren willt, Deine Sache. Dein Auto Für eine Diskussion benötigt man Daten. Wenn es keine (nachvollziehbaren) Quellen gibt, bleibt alles Spekulation. Für eine "Diskussion" fehlt dann die Grundlage. Ich finde die Beiträge zu den "möglichen" (!) Hintergründen interessant. Sie bieten Ansätze für eigene Tests (für diejenigen die denn Interesse und Mittel haben). Aber nicht mehr. Piter K. schrieb: > FAT hat starre STamm-Verzeichnisstruktur, mehr aber auch nicht. Der Host > kann dann trotzdem auf der Karte wild herum schreiben, was hilft es dem > Wearleveling zu vermuten, daß auf die stamm directories öfter > geschrieben wird? Caches. Separates Wear Levelling. Backup. (Alles um die Karte zuverlässiger und schneller zu machen.) Wurde hier im Forum schon Mal geschrieben. Ist jetzt nicht wirklich undenkbar. So, oder so, es bleibt Spekulation. Falls noch jemand Interesse an der Eingangsdiskussion hat und Studien für den Ausfall von SD Karten durch Spannungsausfall hat, ich würde mich über Beiträge freuen.
Piter K. schrieb: > Wie wäre es: Flashblock löschen, neuen Inhalt schreiben und hinten dran > die Checksum anhängen, dann Block auslesen, Checksum bilden und mit der > gelesenen vergleichen.... zu schwer? Während jedes dieser Vorgänge kann der Strom ausfallen, z.B. durch Ziehen der Karte im laufenden Betrieb. Der kritischste Vorgang ist hierbei das Löschen des Flashblocks. Wie von mir oben schon ausgeführt, können bei einer Unterbrechung dieses Vorganges noch Restladungen in der Flashzellen zurückbleiben, die sich beim späteren Beschreiben dann als Bitfehler bemerkbar machen können, insbesondere bei Bausteinen, die mir als ein Bit pro Zelle speichern. Im Gegensatz zu Festplatten enthält eine SD-Karte keine Schwungmasse und auch keinen hinreichend dicken Kondensatoren, um begonnene Operationen auf Low-Level-Ebene noch abzuschließen. > wenn der Flash sagen wir mit 256kb blöcken arbeitet, kann man doch > locker einen 512 byte "sektor" in jedem 256kb Block "opfern" um dort die > Checksum zu speichern, das wären nicht mal 0.2% Kapazitätsverlust. Es gibt durchaus Flashbausteine mit (2^n)+x großen Blöcken, z.B. die Dataflash-Serie AT45 von Atmel, neuerdings Adesto, die für derartige Zwecke vorgesehen sind. http://www.adestotech.com/products/data-flash/ Atmel hatte damals(tm), d.h. um 2005, sogar versucht, diese Dataflashes als SD-Karten zu etablieren, ist damit aber ziemlich untergegangen. Für das Gerät, das ich damals mit einem Kunden entwickelte, gab es eine spezielle Aufsteckleiterplatte mit einem Dataflash-SD-Halter, was sich während der Entwicklungsphase als durchaus praktisch erwies. https://www.tedss.com/2099002755 Wirklich durchgesetzt haben sich diese Bausteine aber nicht, da es keine hinreichend verbreiteten Dateisysteme gibt, die diesen Zusatzspeicher ausnutzen. Nur von Atmel gab es einen unter NDA erhältlichen Treiber, der allerdings nur für "nackte" Controllerfirmware geeignet war und nicht z.B. für Linux. Daher nutzten wir das ganz normale JFFS2.
Wenn wir schon bei dem Wikipedia bleiben, dort steht was von exFAT mandatory für SDXC... ok, einverstanden daß das so sein kann (wundert mich in dieser korrupten Welt überhaupt nicht, da es wieder so eine proprietary MS Sch**** mit hohen Lizenzgebühren ist). Ich habe aber noch nie was gehört von FAT mandatory für SDHC. Meine arme Kingston Karte war auch eine SDHC! Was mich noch interessieren würde, wäre ein Diagnosetool, ein Sketch für Arduino vielleicht, wo ich die SD dran anschließen könnte und eventuell was über die Ursache des Ausfalls erfahren könnte (mit Umgehung des USB controllers). Falls also jemand so was kennt, bitte her damit. Bleiben wir konstruktiv. Schließlich sind wir in diesem Forum, um Ursachenforschung zu betreiben.
Baldrian schrieb: > Belastbare Links, Quellen & Informationen müssen her. Geschichten mit > NDA u. ä. helfen nicht weiter. Ich werde bestimmt nicht zu meinem Kunden rennen und ihm die entsprechenden Dokumente abluchsen, um sie hier zu verbreiten.
Mikro 7. schrieb: > Falls noch jemand Interesse an der Eingangsdiskussion hat und Studien > für den Ausfall von SD Karten durch Spannungsausfall hat, ich würde mich > über Beiträge freuen. mich würde interessieren, ob der von mir vorgeschlagene Adapter mit Backup-Spannungsversorgung für die SD Karte sinn macht? Und falls das so ist, hätte so eine Schaltung eigentlich direkt in den PI gehört....
Hier noch mal der Link, falls er untergegangen ist: http://elinux.org/RPi_SD_cards#Working_.2F_Non-working_SD_cards Samsung, Lexar, Toshiba, Sony weniger problematisch als der Rest.
Andreas S. schrieb: > Während jedes dieser Vorgänge kann der Strom ausfallen, z.B. durch > Ziehen der Karte im laufenden Betrieb. Der kritischste Vorgang ist > hierbei das Löschen des Flashblocks. Wie von mir oben schon ausgeführt, Darum werden in einem Transaktionsmodell die "alten" Daten erst gelöscht nachdem die neuen Daten geschrieben wurden. Dafür braucht man mit entsprechenden großen Window (um den Durchsatz nicht einbrechen zu lassen) mehr Pages. Technisch sehe ich kein grundsätzliches Problem. Mit der o.g. Zeit von 1s Delay würden die alten Pages freigegeben und die Verlinkung aktualisiert. Hört sich für mich nicht soo kompliziert an. Aber, aus leidvoller Erfahrung, der Teufel steck ja manchmal wirklich im Detail.
Piter K. schrieb: > 2.0 SSD, Flash Card and USB Flash Drive Capacity > Some of a Flash storage device’s listed capacity is used for formatting > and other functions and thus is not available > for data storage. Was verstehst Du an "other functions" nicht? > When a Flash storage device is designed and manufactured, steps are > taken to ensure that the device operates > reliably and to permit the host device (computer, digital camera, > tablets, mobile phone, etc.) to access the memory > cells — i.e., to store and retrieve data on the Flash storage device. > Formatting includes the following operations: Da steht doch "manufactured" und "Formatting". Das ist so zu lesen, dass die Formatierung während der Herstellung erfolgt. Für den späteren Gebrauch sind die Anwendungsfälle "store data" und "retrieve data" definiert, d.h. Dateizugriffe gemäß für den vorkonfigurierten Dateisystemtyp üblichen Konventionen. Dass hierbei keine beliebige Operationen auf Sektorebene gemeint sind, folgt dann wiederum aus der SD-Spezifikation. > <Punkte 1 bis 5> Dort ist explizit aufgeführt, welche Schritte während der Herstellung erfolgen, und dazu gehört insbesondere auch Punkt 4: "Creating a File Allocation Table (FAT) or other directory." > 6. Where applicable, reserving some cells for special features. For > example, the specification for Secure Digital (SD) > cards requires reserved areas to support special copy protection and > security features. Die Karten können also Sektoren, Blöcke o.ä. enthalten, die Sonderfunktionen bewirken. Erzeugt man also sein eigenes Dateisystem, können dadurch auch solche reservierten Blöcke zwecksentfremdet werden, was beliebige ulkige Auswirkungen haben kann. > => es wird nicht behauptet FAT ist irgendwie obligatorisch.... Es wird ganz klar gesagt, dass die Formatierung und damit die Festlegung des Dateisystemtyps während der Herstellung erfolgt und zu keinem anderen Zeitpunkt. Die Zweckentfremdung von Block Devices und entsprechender Pseudodateisysteme ist übrigens auch bei ganz anderen Anwendungen üblich. Manche USB-Geräte melden sich als Mass Storage und stellen sogar ein FAT-Dateisystem bereit. Dieses ist aber ggf. überhaupt nicht mit Flash oder RAM-Disk o.ä. hinterlegt, sondern wird von der Gerätefirmware nur simuliert. Wer nun versucht, solch ein Gerät zu formatieren, wird auch seine Überraschung erleben. Im einfachsten Fall passiert einfach gar nichts und die alte Struktur bleibt erhalten. Ansonsten stürzt ggf. die Firmware ab. Ein weiteres sehr großes Anwendungsfeld für derartige zweckentfremdete Block Devices sind große Speichergeräte, d.h. RAID-Systeme bzw. SAN. Bei EMC werden sie als sog. "Gatekeeper Device" bezeichnet. Die Konfiguration solcher Speichergeräte erfolgt also nicht etwa über entsprechende SCSI/Fibrechannel-Konfigurationskommandos, sondern durch Schreibzugriffe auf das Gatekeeper Device. Der große Vorteil besteht darin, dass man keinen speziellen (SCSI-)Gerätetreiber für die Konfiguration oder Zugriff auf den "generic"-Treiber (z.B. /dev/sg<n> unter Linux) benötigt, sondern nur ein normales Block Device. Man sollte sich natürlich auch hier tunlich hüten, solch ein Gatekeeper Device mit seinem Lieblingsdateisystem zu formatieren.
:
Bearbeitet durch User
Andreas S. schrieb: > Dort ist explizit aufgeführt, welche Schritte *während der Herstellung* > erfolgen, und dazu gehört insbesondere auch Punkt 4: "Creating a File > Allocation Table (FAT) or other directory." dir ist aber schon klar, daß das physische SDHC interface nichts von einem filesystem weiß? Dort werden nur Datenblöcke geschaufelt, auf einer Ebene noch tiefer als ein Block device. KEINE Spur von irgendwelchen Filesystem-relevanten Befehlen etc. Wenn nun implizit nur ein FAT system vorausgesetzt wird dann ist das ein klarer Verstoß gegen jedes OSI Model und sonstige gute Designrichtlinien. Und ich kann mir nicht vorstellen, daß ein Gremium wie SDcard foundation so einen Mist verzapft. Ganz ehrlich nicht. Ansonsten hätte man das SD Interface auch auf Filesystem-lvl entwickeln sollen... also keine Datenblöcke-Schreiben sondern eher: command <lege ein directory an> command <lege ein file an> schreibe <file> etc.... so weit klar? Was Du behauptest ist eine esoterische Datenübertragung. Schreiben/Lesen im OS nach einer definierten Struktur (FAT) --> Übertragung über ein SD Interface das von der Struktur NICHTS weiß und auch die logischen Information darüber nicht transportieren kann --> Rekonstruktion der angenommenen Struktur des OS im Controller der SD Karte. Bildhaft gesprochen Du überträgst ein Farbbild über eine schwarz-weiß Strecke um es dann am Ziel auf Grund von Annahmen wieder in eine Farbversion zu verwandeln. Geht nicht lange gut.
Piter K. schrieb: > Wenn nun implizit nur ein FAT system vorausgesetzt wird dann ist das ein > klarer Verstoß gegen jedes OSI Model und sonstige gute > Designrichtlinien. Und ich kann mir nicht vorstellen, daß ein Gremium > wie SDcard foundation so einen Mist verzapft. Ganz ehrlich nicht. Weißt Du was: Dann glaub das halt nicht. Ist mir dann auch irgendwie egal.
Piter K. schrieb: > Rufus Τ. F. schrieb: >> Piter K. schrieb: >>> => es wird nicht behauptet FAT ist irgendwie obligatorisch.... >> >> Das gibt der SD-Standard vor. In dem steht, daß SD-Karten mit FAT16, >> SDHC-Karten mit FAT32 und SDXC-Karten mit exFAT zu formatieren sind. >> > > das gibt es nicht vor, es wird nur empfohlen und zwar aus > Effizienzgründen... FAT16 kann ab einer gewissen Größe nicht mehr > sinnvoll arbeiten. Ab welcher Größe soll denn das sein? SD-Karten, die sich an den Standard halten, dürfen nur max. 2 GB groß sein. Und bei FAT16 geht eh nur max. 4 GB.
Andreas S. schrieb: >> 6. Where applicable, reserving some cells for special features. For >> example, the specification for Secure Digital (SD) >> cards requires reserved areas to support special copy protection and >> security features. > > Die Karten können also Sektoren, Blöcke o.ä. enthalten, die > Sonderfunktionen bewirken. Erzeugt man also sein eigenes Dateisystem, Nö. Das steht "cell" nicht "block". cell = "interne" Speichereinheit block = "extern adressierbare" Speichereinheit > können dadurch auch solche reservierten Blöcke zwecksentfremdet werden, > was beliebige ulkige Auswirkungen haben kann. Das wäre in der Tat "ulkig". Gut, dass sie nicht zweckentfremdet werden können.
Andreas S. schrieb: > Baldrian schrieb: >> Belastbare Links, Quellen & Informationen müssen her. Geschichten mit >> NDA u. ä. helfen nicht weiter. > > Ich werde bestimmt nicht zu meinem Kunden rennen und ihm die > entsprechenden Dokumente abluchsen, um sie hier zu verbreiten. Ob du etwas tust oder nicht ist irrelevant. Meine obige Aussage ist eindeutig und ist keine Aufforderung, dass du zu deinem "Kunden" rennen sollst. Deine gesamten Einlassungen sind ohne Subtanz. Du fühlst dich einfach nur gedrängt irgendwelche Meinungen zu äußern.
Piter K. schrieb: > Wenn nun implizit nur ein FAT system vorausgesetzt wird dann ist das ein > klarer Verstoß gegen jedes OSI Model und sonstige gute > Designrichtlinien. Ein Steuergerät eines Autos sollte auch einfach immer das selbe tun. Und trotzdem gibt es da welche, die sich an bestimmte Betriebszustände anpassen... Wie ich schon schrieb: in ihrem Drang, ein sicheres Speichermedium zu bauen, gehen die Programmierer über die Norm hinaus und versuchen herauszufinden, welches FS da werkelt und passen ihr Speichermanagement daran an. Und wenn sie nichts herausfinden, dann geht es zurück in den Defaultmodus. Überlege einfach mal, wie du das machen würdest, wenn dein Chef käme und zur OSI konformen Implementation sagt: Das muss aber noch besser werden!
:
Bearbeitet durch Moderator
der Grund für die "mit FAT vorformatiert" Anforderung für SD-Cards war folgender: SD/MMC-Karten-Controller sollten möglichst dumm (=billig) möglich sein. d.H. Kein Wear-Leveling, stattdessen ein "High Endurance" Block da, wo die FAT liegt. Kein dynamisches Remapping, und kein Defekt-Management, defekte Blöcke sollen in der Factory-Formatierung einfach in der FAT "wegmarkiert" werden. Neuformatieren/Anderes Dateisystem ==> Karte Schrott. mit MLC/TLC ist sowas natürlich nicht mehr realistisch möglich, und durch Verwendung eines "Kleineren" SD-Controllers ist in der Masse auch nicht wirklich Geld gespart. Ich glaube nicht, dass es heute solche "Dummen" Karten gibt, kenne auch keine Fälle wo früher sowas produziert wurde. Aber es sollte halt eben möglich sein, deshalb wurde es in die Spec aufgenommen. der Grund für die exFAT-Anforderung bei SDXC: Microsoft will Lizenzgebühren, das Patent auf FAT ist abgelaufen. Sorry, dieser Post entspricht nicht den Forums-Nutzungsbedingungen. Bitte löschen.
Lothar M. schrieb: > Wie ich schon schrieb: in ihrem Drang, ein sicheres Speichermedium zu > bauen, gehen die Programmierer über die Norm hinaus und versuchen > herauszufinden, welches FS da werkelt und passen ihr Speichermanagement > daran an. Und wenn sie nichts herausfinden, dann geht es zurück in den > Defaultmodus. Oder sie halten sich einfach an die Spec (§14 Speed Class Definition), die die Speed-Class an den Begriff "FAT" und "Directory" festmacht -- was man mit gutem Willen bspw. als FAT32 + Root Directory auslegen könnte. @Various Der Blockzugriff muss immer funktionieren. Und daher auch jedes Dateisystem. Der Begriff "FAT" in §14 wird lediglich im Rahmen der Speed Class genutzt.
Unglaublich. Du regst Dich hier über einen Hersteller auf der Dir anbietet Ersatz zu liefern für ein Produkt welches Du außerhalb der Spezifikation betrieben und zerstört hast!? Raspberry Pi sind reine Hobbygeräte und SD Karten nicht als Systemspeicher vorgesehen. Der Fehler liegt zu 100% bei Dir, weil Du meinst nur weil viele das so machen wäre es richtig...
Piter K. schrieb: > Ich habe aber noch > nie was gehört von FAT mandatory für SDHC. Erstens: Für SDHC ist FAT32 mandatory. Zweigens: Das wurde hier schon oft durchgekaut, steht bei Wikipedia und ich habe dir zudem verraten, wo du den passenden Standard finden und dich selbst bilden kannst. Verlinken werde ich ihn aber nicht, denn er ist nicht öffentlich und ich mag weder gegen Gesetze noch die Forenregeln verstoßen. Piter K. schrieb: > dir ist aber schon klar, daß das physische SDHC interface nichts von > einem filesystem weiß? Das spielt keine Rolle. Dein Ethernet-Kabel weiß auch nichts von Präambeln und MAC-Adressen, trotzdem ist es ohne diese Dinge kein Ethernet-Kabel. Piter K. schrieb: > Und ich kann mir nicht vorstellen, daß ein Gremium > wie SDcard foundation so einen Mist verzapft. Dann lies die Dokumente, ich habe im Rahmen des Möglichen zitiert, Quellen und Referenzen gegeben, und wenn du jetzt noch immer der Meinung bist, es sei nicht so, dann bist du sowohl ein Idiot als auch ein Troll. Baldrian schrieb: > Deine gesamten Einlassungen sind ohne Subtanz. Du fühlst dich einfach > nur gedrängt irgendwelche Meinungen zu äußern. Wenn ich wegen eines NDA einen Fakt nicht im Detail berichten darf, aber darauf hinweisen darf, dass eine dargestellte Position falsch ist - weil ich darüber informiert bin - dann ist das substanzlos? Das heißt, du lebst gerne in Fantasiegebilden, denn nichtöffentliche Informationen existieren für dich nicht. Gratuliere, du wärst im Mittelalter gut aufgehoben.
Ich habe mit einer 128GB uSD Karte meines Sohnes Probleme wurde nur als exFAT im Kindle Für verwendet. Und hoffe das mir hier aufgrund folgender Aussage "And in case of exFAT file system, Allocation Bitmap shall be stored in the first 4MB of Cluster Heap." jemand helfen kann. Könnte mir jemand genau diese ersten 4MB einer 128GB einer Sandisk uSD Karte zusenden evtl. per DD ausgelesen. Die Karte ist lesbar aber nicht mehr beschreibbar. Formatieren sowohl unter Debian Linux als auch unter Win7 wird mit einer Fertigstellungsmeldung bestätigt. Die Karte wird aber nicht verändert erst chkdsk aus der Eingabeaufforderung aufgerufen brache eine Fehlermeldung die auf Allocation Bitmap Fehler schließt.
:
Bearbeitet durch User
Thomas O. schrieb: > Könnte mir jemand genau diese ersten 4MB einer 128GB einer Sandisk uSD > Karte zusenden evtl. per DD ausgelesen. Was bringt Dir das? Die "allocation bitmap" ist Bestandteil des Dateisystems und ihr Inhalt von der jeweiligen Belegung des Dateisystems abhängig. Sie besagt, welche Bereiche des Dateisystems von Dateien belegt und welche nicht belegt sind (und ist damit das Äquivalent der FAT, die im gleichnamigen Dateisystem für diesen Zweck verwendet wird).
Vielleicht hilft ja die Allocation Bitmap einer leeren Karte. Ich dachte eben das ich da wieder etwas geradebiegen kann was nicht mehr passt. Da die Karte ja eh nicht mehr funktioniert habe ich ja nichts zu verlieren.
Lothar M. schrieb: > Wie ich schon schrieb: in ihrem Drang, ein sicheres Speichermedium zu > bauen, gehen die Programmierer über die Norm hinaus und versuchen > herauszufinden, welches FS da werkelt und passen ihr Speichermanagement > daran an. Und wenn sie nichts herausfinden, dann geht es zurück in den > Defaultmodus. Das ist ja OK. Aber die Behauptung ein anderes FS als FAT würde die Karte ruinieren kann einfach nicht wahr sein. Wie ich schon sagte: das wear leveling muss funktionieren, EGAL wo auf die Karte geschrieben wird. Wenn sich eine Anwendung entschließt wild irgendwo mitten in FAT Files hineinzuschreiben dann ist das auch nicht anders als wenn ein anderes FS drauf ist.
Historiker schrieb: > der Grund für die "mit FAT vorformatiert" Anforderung für SD-Cards war > folgender: > > SD/MMC-Karten-Controller sollten möglichst dumm (=billig) möglich sein. > d.H. Kein Wear-Leveling, stattdessen ein "High Endurance" Block da, wo > die FAT liegt. > Kein dynamisches Remapping, und kein Defekt-Management, defekte Blöcke > sollen in der Factory-Formatierung einfach in der FAT "wegmarkiert" > werden. ... > der Grund für die exFAT-Anforderung bei SDXC: Microsoft will > Lizenzgebühren, das Patent auf FAT ist abgelaufen. Ja das macht so Sinn. Allerdings können auch andere FS defekte Blöcke umgehen, also Schrott ist die Karte dann noch nicht.
Noch ein schrieb: > Unglaublich. Du regst Dich hier über einen Hersteller auf der Dir > anbietet Ersatz zu liefern für ein Produkt welches Du außerhalb der > Spezifikation betrieben und zerstört hast!? > > Raspberry Pi sind reine Hobbygeräte und SD Karten nicht als > Systemspeicher vorgesehen. > > Der Fehler liegt zu 100% bei Dir, weil Du meinst nur weil viele das so > machen wäre es richtig... Wieder mal so ein Schlaumeier... Dummerweise kommt der RPI mit SD Kartenslot daher. Was soll ich deiner Meinung nach da rein stecken? Eine CFFlash etwa? Erst denken DANN schreiben!
c.m. schrieb: > Jim M. schrieb: >> Kingston verbaut den billigsten Flash im Markt - die Dinger gehen >> relativ bald kaputt, und haben eher wechselhafte Qualität. > > interessante fakten zum thema: > Youtube-Video "30C3: The Exploration and Exploitation of an SD Memory > Card (EN)" Sehr interessanter Vortrag - und eine der wichtigsten Botschaften ist ja, das SD Karten extrem unzuverlässige Datenspeicher sind und ein Preiskampf in diesem Segment herrscht, der jegliche Datensicherheit illusorisch macht.
Matthias S. schrieb: > ... eine der wichtigsten Botschaften ist > ja, das SD Karten extrem unzuverlässige Datenspeicher sind ... Nein. > ... ein Preiskampf in diesem Segment herrscht, ... Ja. > ... der jegliche Datensicherheit illusorisch macht. Nein.
Matthias S. schrieb: > Sehr interessanter Vortrag - und eine der wichtigsten Botschaften ist > ja, das SD Karten extrem unzuverlässige Datenspeicher sind und ein > Preiskampf in diesem Segment herrscht, der jegliche Datensicherheit > illusorisch macht. Erinnert sich noch jemand an CD-Rohlinge? Da war es am Ende nicht anders.
Noch ein schrieb: > Unglaublich. Du regst Dich hier über einen Hersteller auf der Dir > anbietet Ersatz zu liefern für ein Produkt welches Du außerhalb der > Spezifikation betrieben und zerstört hast!? Nochmal um das klar zu stellen: ich rege mich nicht über einen bestimmten Hersteller auf und betreibe auch kein Bashing. Es wurde nicht hinreichend begründet, ob die SD Karte außerhalb der Spec betrieben wurde... (eigentlich wurde es überhaupt nicht begründet, sondern nur auf zweideutige Klauseln verwiesen). Ersatz wäre gut und schön, ich kann aber schwer eine Karte zum Umtausch einschicken, die eventuell "Firmengeheimnisse" (code etc) im Flash enthält. Selbst wenn ich den Flash nicht lesen kann, k.a. was das Testlabor bei Kingston damit macht und welche Möglichkeiten die haben. So weit verständlich? Und wenn mir nun jede Woche eine Karte kaputt geht, was mache ich dann? Finde die Ursachenforschung durchaus begründet.
Übrigens: und das soll wirklich NICHT gegen einen bestimmten Hersteller gehen... mir ist schon vor ca. 2 Jahren eine 128GB Kingston V300 SSD verreckt. Konnte den Ausfall damals nicht nachvollziehen. Die SSD war normal im Laptop drin und irgendwann war sie einfach mausetot nach einem Reboot, nach nicht einmal 1 Monat. Device nicht mehr erkannt. Vorher keine Fehlermeldung, nichts. TBW wurde auf keinen Fall erreicht, nicht im Leben. Durch Xray bin ich damit auch nicht gegangen. Das Laptop stand nur im Büro rum. Ich konnte die V300 aus den gleichen Gründen nicht zum Austausch einschicken, als Lehrgeld abgehackt und seit dem keine SSD mehr angefasst. Ich lebe mit klassischen HDDs viel entspannter. (wann kommt nun der erste, um mir weiß zu machen daß SSD bitte nur mit VFAT zu formatieren sind?).
S. R. schrieb: > Das spielt keine Rolle. Dein Ethernet-Kabel weiß auch nichts von > Präambeln und MAC-Adressen, trotzdem ist es ohne diese Dinge kein > Ethernet-Kabel. wieder mal so ein Äpfel und Birnen vergleich... Natürlich ist ein Ethernet-Kabel immer ein Ethernet-Kabel. Selbst wenn es gerade nicht angeschlossen ist.
Baldrian schrieb: >> ... eine der wichtigsten Botschaften ist >> ja, das SD Karten extrem unzuverlässige Datenspeicher sind ... > > Nein. >> ... ein Preiskampf in diesem Segment herrscht, ... > Ja. >> ... der jegliche Datensicherheit illusorisch macht. > Nein. Schau dir den Vortrag mal an. SD Karten werden grösstenteils aus Schrott zusammengebaut. Jegliche Datensicherheit ist nur ein Wunsch des Käufers (und du glaubst da anscheinend dran). Woher nimmst du deinen Glauben? Bist du so ein Hersteller? Wo Preiskampf herrscht, bleibt immer die Qualität auf der Strecke. Ob das Airlines oder SD Karten Hersteller sind, spielt dabei keine Rolle. Es gibt nur eine Handvoll Hersteller, bei denen das manchmal etwas besser ist.
:
Bearbeitet durch User
Matthias S. schrieb: > Schau dir den Vortrag mal an. SD Karten werden grösstenteils aus Schrott > zusammengebaut. Jegliche Datensicherheit ist nur ein Wunsch des Käufers > (und du glaubst da anscheinend dran). So kann das auch wieder nicht stimmen. Bei 128 & 200GB MicroSD Karten ist dort derzeit die Grenze des Machbaren erreicht. Mehr stacked Dies passen nicht mehr in die Karte. D.h. bei den hohen Kapazitäten muss man Flashchips verbauen, die wenig Defekte haben, sonst kann man die Kapazität nicht erreichen. Bei den kleinen Größen sieht es dementsprechend anders aus. Kann mir gut vorstellen, daß die Hersteller mittlerweile nur noch 64 & 128GB Dies backen und daraus dann 128,6432,16 usw Karten "bauen" durch abschalten der kaputten Zellen.
Piter K. schrieb: > S. R. schrieb: > >> Nein, das Dateisystem ist im Standard festgeschrieben. >> Eine SDHC-Karte mit ext4 ist keine standardkonforme SDHC-Karte mehr. > > Referenz? Angabe von Quelle und Paragraph bitte. SD Specifications Part 2 File System Specification Version 3.00
Piter K. schrieb: > Noch ein schrieb: >> Der Fehler liegt zu 100% bei Dir, weil Du meinst nur weil viele das so >> machen wäre es richtig... > > Wieder mal so ein Schlaumeier... Dummerweise kommt der RPI mit SD > Kartenslot daher. Was soll ich deiner Meinung nach da rein stecken? Eine > CFFlash etwa? Einfach keinen Pi nehmen wäre beispielsweise ein gangbarer Weg. Bei Raw NAND Flash ist es Sache des Betriebssystems und dort des Flash File Systems, Wear Leveling und Bad Block Management zu machen. Da gibts auch keinen Controller, der dann einfach die Schotten dicht macht. Für mich klingt das einfach nach zu billig gekauft. Da hält sich mein Mitleid in Grenzen. Und im Notfall machst Du Dir einfach eine kleine PCB, die auf der einen Seite in einnen uSD-Slot passt und auf der anderen Seite einen eMMC-Baustein enthält, plus 2*2u2 und 2*100n. fchk
Frank K. schrieb: >> Referenz? Angabe von Quelle und Paragraph bitte. > > SD Specifications Part 2 File System Specification Version 3.00 http://read.pudn.com/downloads188/ebook/881633/SD%203.0/Part_2_File_System_Specification_V3.00_Final_090416.pdf Ist das etwa das hier? (vom LKW gefallen...) Da steht zwar tatsächlich drin: https://s23.postimg.org/fjrhjrfi3/sdhc.png Allerdings vom Sprachgebrauch her, bezieht sich das auf die dort vorhandene Tabelle. Es wird zwar "verboten" eine 8GB Karte mit FAT16 teilzuformatieren etc, heißt aber wiederum:
1 | This specification specifies some file systems. The type of the file system to be used shall be uniquely decided with Card Capacity as follows... |
Ansonsten müßte es heißen (o.ä.): This specification specifies following exclusively allowed file systems... Denn sonst auf gut Deutsch klingt das: die Spezifikation definiert ein paar Filesysteme... davon soll je nach Größe... FAT VFAT exFAT benutzt werden. Es steht nirgends dort, daß ANDERE Filesytem generell verboten sind, sondern nur, daß eben nur FAT/VFAT/exFAT in der Spezifikation definiert sind.
Piter K. schrieb: > Denn sonst auf gut Deutsch klingt das: die Spezifikation definiert ein > paar Filesysteme... davon soll je nach Größe... FAT VFAT exFAT benutzt > werden. > > Es steht nirgends dort, daß ANDERE Filesytem generell verboten sind, > sondern nur, daß eben nur FAT/VFAT/exFAT in der Spezifikation definiert > sind. Andere Filesysteme sind außerhalb der Spezifikation und können funktionieren, die Karte in Antimaterie verwandeln oder beliebige andere Dinge tun. Wie Du ja selbst erlebt hast. "shall" heißt in Standards eigentlich immer, dass man tunlichst der Empfehlung folgen sollte, wenn man nicht auf die Nase fallen möchte. fchk
Eine Denkaufgabe habe ich noch: was passiert, wenn ich eine SDHC Karte zwar mit VFAT formatiere, dort aber ein einziges großes File anlege, in welchem dann ein EXT3 filesystem liegt (in Linux über ein loop device z.b.) und den ganzen Speicherplatz (ab block X bis MAX) belegt? Besteht ein Unterschied zu Block X bis MAX direkt als EXT3 partition zu nutzen?
Frank K. schrieb: > Andere Filesysteme sind außerhalb der Spezifikation und können > funktionieren, die Karte in Antimaterie verwandeln oder beliebige andere > Dinge tun. > Wie Du ja selbst erlebt hast. "shall" heißt in Standards eigentlich > immer, dass man tunlichst der Empfehlung folgen sollte, wenn man nicht > auf die Nase fallen möchte. Ich interpretiere die Spec im Sinne von Gebot und nicht Verbot. SDHC ist ja ein Austauschmedium, man will ja erreichen daß ich eine Karte z.b. aus einer Kamera entnehmen kann und sie in mein Smartphone legen kann. Deshalb wird auch ein FS angegeben, damit die Geräte ein Minimum an Funktionalität haben. Sonst wäre Interoperabilität nicht gewährleistet. Ist ja auch sinnvoll. Daraus aber abzuleiten "ein anderes FS zerstört die Karte", oder "wear leveling ist auf FAT zugeschnitten" greift mir zu kurz. Das kann man sich in die Spec so hinein fabulieren, um es sich einfach zu machen, steht dort aber nicht wirklich drin. Ist stimme dem Vorredner zwar zu, daß eine SD Karte ohne FAT (oder FAT nicht nach der Tabele in der Spec) keine SD Karte nach SD card standard ist. Ich erwarte aber auch nicht, daß sie dann von meiner SD-ready Digicam gelesen wird. Nach wie vor fehlen hier belastbare Quellen, warum die Karte zerstört werden könnte ohne FAT.
Samsung SD Karten gehen bei mir und im Verwandtenkreis, obwohl fast nie der Stecker gezogen wird, oft kaputt in Raspis. Kann ich nicht empfehlen. Lieber eine andere Marke nehmen. LG
Paul B. schrieb: > Samsung SD Karten... > Kann ich nicht empfehlen Ja, so gehen die Erfahrungen auseinander.... Hast du zu "wie oft" und "wie viele" und "welche" auch noch Daten? Besonders der Kartentyp wäre interessant, dann würde ich die auch mal kaufen und testen. Weil damit dann ja meine Annahme "gleicher Hersteller = gleiche Firmware) widerlegt wäre. Welche Karten würdest du stattdessen empfehlen?
:
Bearbeitet durch Moderator
wie heißt eigentlich das Gegenteil von dd /dev/zero... ich wollte mal die Karte mit 1er überschreiben, vielleicht setzt es das write protect bit in der protectet area, irgendwie scheint es ja auch verändert worden zu sein oder gibt es da kein Weg zurück? Einmal gesetzt und für immer Read only?
Piter K. schrieb: > eventuell ist diese Tabelle hilfreich. Leider nur teilweise, weil dort ja nicht ein bestimmter Fehlermechanismus ge- und untersucht wird, sondern einfach ein paar Karten festgehalten sind, die nicht laufen oder auch (bisher) problemlos laufen. Bestenfalls statistisch lässt sich hier sagen, dass es evtl. was brächte, die "Schlechteste" und die "Beste" aus dieser Tabelle in einem objektiven Test mit größerer Stückzahl miteinander zu vergleichen.
Ich glaube, ich habe einen großen Teil des Textes hier gelesen, aber es ist anscheinend noch niemand auf das große geheime "S" in der SD-Karte eingegangen, welches sie von der MM-Card unterscheidet. Genau in diesem S und den damit in Verbindung stehenden undokumentierten Funktionen liegt doch die eigentliche Wurzel allen Übels, weil genau an dieser Stelle alle weiteren Analyseversuche zur Controllerfirmware scheitern und niemand weiß was wirklich in der Karte vor sich geht...
Lothar M. schrieb: > Piter K. schrieb: >> eventuell ist diese Tabelle hilfreich. > Leider nur teilweise, weil dort ja nicht ein bestimmter > Fehlermechanismus ge- und untersucht wird, sondern einfach ein paar > Karten festgehalten sind, die nicht laufen oder auch (bisher) problemlos > laufen. Das stimmt aber das von mir beschriebene Problem scheint auch in manchen Kommentaren zu den Karten aufzutauchen. Also doch nicht so unwahrscheinlich...
Piter K. schrieb: > Das ist ja OK. Aber die Behauptung ein anderes FS als FAT würde die > Karte ruinieren kann einfach nicht wahr sein. Die Praxis zeigt doch aber genau dieses Verhalten, d.h. Karten mit abweichender Formatierung sind teilweise wesentlich unzuverlässiger. > Wie ich schon sagte: das > wear leveling muss funktionieren, EGAL wo auf die Karte geschrieben > wird. Das ist die Definition eines perfekten Datenträgers. Leider trifft diese Definition nicht auf reale Produkte zu, insbesondere wenn diese auch noch allen möglichen anderen Zwängen unterliegen: Platzbedarf, Stromversorgung, Kosten. > Wenn sich eine Anwendung entschließt wild irgendwo mitten in FAT > Files hineinzuschreiben dann ist das auch nicht anders als wenn ein > anderes FS drauf ist. Bei FAT und allen anderen nicht auf Flash optimierten Dateisystemen besteht das grundlegende Problem, dass einige Sektoren/Blöcke bei Schreibvorgängen sehr stark belastet werden und andere weniger, nämlich wegen der Unzahl an Metaoperationen. Bei Flash ist auch nicht das Schreiben der zerstörende Vorgang, sondern das Löschen von Blöcken. Bei "ordentlichen" Flash-Dateisystemen versucht man, die Zahl der Löschvorgänge zu minimieren. Es ist durchaus möglich, Speicher in einer Richtung zu überschreiben, z.B. nachträglich weitere 1 in 0 zu ändern, ohne den Block vorher löschen zu müssen. Dies kann ein Dateisystem durchaus ausnutzen, um z.B. Verzeichnis- und Belegungslisten zu aktulisieren bzw. auch als "verbraucht" bis zum nächsten Löschvorgang zu markieren. Bei Flashzellen mit mehrwertiger Logik kann die Betrachtung leider nicht auf Einzelbitebene erfolgen, sondern ggf. auf Bitgruppenebene. Bei der Konfiguration von Flash-Dateisystemen wie z.B. JFFS2 werden daher etliche Parameter angegeben, z.B. die Löschblockgröße. All diese Informationen sind nicht bei normalen Speicherkarten verfügbar. Daher muss die Kartenfirmware versuchen, die ganzen Vorgänge im Hintergrund zu optimieren, wohlwissend dass jederzeit der Strom ausfallen kann.
:
Bearbeitet durch User
Piter K. schrieb: > dir ist aber schon klar, daß das physische SDHC interface nichts von > einem filesystem weiß? Dort werden nur Datenblöcke geschaufelt, auf > einer Ebene noch tiefer als ein Block device. KEINE Spur von > irgendwelchen Filesystem-relevanten Befehlen etc. Selbstverständlich weiß ich das. Und genau darin besteht ja das große Problem: die Kartenfirmware muss ein Wear Leveling durchführen, da die "normalen" Dateisysteme so etwas nicht berücksichtigen, und dabei muss die Kartenfirmware irgendwelche Annahmen treffen. > Wenn nun implizit nur ein FAT system vorausgesetzt wird dann ist das ein > klarer Verstoß gegen jedes OSI Model und sonstige gute > Designrichtlinien. Die Argumentation mit "jedem OSI Model" ist die völliger Unsinn. Das OSI-Modell ist ein Referenzmodell für Netzwerkprotokolle und nicht mehr oder weniger. Nicht jedes Schichtenmodell ist an das OSI-Modell angelehnt, auch wenn viele Idioten mit gefährlichem Halbwissen dies immer wieder behaupten. Nicht einmal TCP/IP entspricht dem OSI-Modell. Die Implementierung des OSI-Protokolls auf Basis des OSI-Modells ist schon vor langer Zeit gescheitert, da es sich als nicht praktikabel erwiesen hat. Dennoch wurden aber auch einige Teilfunktionalitäten in andere Netzwerkprotokolle übernommen, z.B. aus X.400 für E-Mails oder X.500 für LDAP/Active Directory. Andere Teile findet man noch in der Vermittlungstechnik (SS7/Q.700) oder im Bankenbereich, z.B. FTAM. Trotzdem handelt es sich eben um keine über alle Schichten durchgängige Implementierung des OSI-Modells. > Und ich kann mir nicht vorstellen, daß ein Gremium > wie SDcard foundation so einen Mist verzapft. Ganz ehrlich nicht. Dann hast Du keine Vorstellung davon, welche Leute häufig in Standardisierungsgremien sitzen. Techniker mit wirklich fundiertem Wissen findet man dort nur äußerst selten, stattdessen zum einen profilierungssüchtige Bürokraten ohne relevanten Sachverstand oder auf das Abstellgleis abgeschobene Entwickler. Die letztgenannten dominieren dann, wenn es z.B. öffentliche Gelder für die Teilnahme an den Sitzungen solcher Gremien gibt. Je weniger dabei herauskommt, desto mehr Sitzungen muss man veranstalten, wodurch man die Nieten hervorragend durchgefüttert bekommt und sich die ganze Sache rechnet. Die Spezifikationen werden dann von den Heißluftdüsen verfasst, die sich dann allerdings im Hintergrund bei fähigen Entwicklern schlau machen. Allerdings werden dann wiederum auch wirklich gute technische Konzepte wieder umformuliert, damit die Heißluftdüse das ganze als eigenen Beitrag darstellen kann. Sehr viele wichtige Spezifikationen enthalten durchaus schwere Entwurfsfehler. Teilweise werden sie in späteren Versionen der Spezifikation korrigiert, wobei aber auf strikte Kompatibilität zu bestehenden Systemen zu achten ist. Teilweise macht aber auch jeder seinen eigenen Workaround, so dass dann im Laufe der Zeit gewisse Standardworkarounds entstehen, die aber ggf. niemals in die eigentliche Spezifikation einfließen. Manchmal funktionieren Geräte, die sich nicht streng an die formalen Spezifikationen halten, sogar wesentlich besser als solche, die auf strikte Spezifikationskonformität achten. Einer der großen Erfolgsfaktoren der Mobiltelefone von Nokia bestand darin, dass sie in sehr vielen Mobilfunknetzen sehr zuverlässig funktionierten. Wenn man solch ein Telefon aber auf dem GSM-Protokolltester untersucht hat, gab es aber gewaltige Überraschungen. Auch in den Protokollstacks etlicher anderer Telefone fand man haufenweise Workarounds für bestimmte Implementierungsfehler bestimmter Firmwarestände der Netzwerkinfrastruktur. Bei einer streng spezifikationskonformen Implementierung hätte das Mobiltelefon dann gar keinen Anruf (oder andere Funktionalität) ausführen dürfen. > Ansonsten hätte man das SD Interface auch auf Filesystem-lvl entwickeln > sollen... also keine Datenblöcke-Schreiben sondern eher: > > command <lege ein directory an> > command <lege ein file an> > schreibe <file> > > etc.... so weit klar? Damals gab es aber komplett andere Entwurfsziele: man benötigte möglichst handliche Speicherkarten, die sich mit möglichst geringem Firmwareaufwand beschreiben lassen. Es stand niemals zur Diskussion, solche Speicherkarten als Haupt-Dateisysteme für "dicke" Linuxrechner o.ä. einzusetzen, so wie es heute ja der Fall ist. Wer "damals" einen Festplattenersatz suchte, war bei Compact Flash richtig aufgehoben und ist es teilweise auch heute noch. > Bildhaft gesprochen Du überträgst ein Farbbild über eine schwarz-weiß > Strecke um es dann am Ziel auf Grund von Annahmen wieder in eine > Farbversion zu verwandeln. Geht nicht lange gut. Was soll eine "schwarz-weiß Strecke" sein? Deine Vergleiche sind völlig unbrauchbar.
:
Bearbeitet durch User
Andreas S. schrieb: > Piter K. schrieb: >> Das ist ja OK. Aber die Behauptung ein anderes FS als FAT würde die >> Karte ruinieren kann einfach nicht wahr sein. Kann nicht wahr sein? > Die Praxis zeigt doch aber genau dieses Verhalten, d.h. Karten mit > abweichender Formatierung sind teilweise wesentlich unzuverlässiger. Die Praxis? Kann einer von Euch seine Behauptung belegen? Also eine Quelle zeigen wo mit FAT und anderen FS getestet und statistisch ausgewertet wurde?
Mikro 7. schrieb: > Kann einer von Euch seine Behauptung belegen? Also eine Quelle zeigen wo > mit FAT und anderen FS getestet und statistisch ausgewertet wurde? +1 Daran wäre ich auch interessiert.
Andreas S. schrieb: > Bei FAT und allen anderen nicht auf Flash optimierten Dateisystemen > besteht das grundlegende Problem, dass einige Sektoren/Blöcke bei > Schreibvorgängen sehr stark belastet werden und andere weniger, nämlich > wegen der Unzahl an Metaoperationen. Bei Flash ist auch nicht das > Schreiben der zerstörende Vorgang, sondern das Löschen von Blöcken. Damit wären wir bei der Frage, wieso man ausgerechnet ein beliebig ungeeignetes Filesystem für die SD Karten als Standard definiert hat... (ich ahne böses... bzw. böse MSachenschaften). Außerdem wie ich schon sagte: der Use-case bestimmt, wo verstärkt geschrieben wird. Das kann auch bei einem FAT Datenträger ganz woanders sein, als es die SD Karte "vermutet" => sollte ein wear lvling wirklich sinn machen (abgesehen von einem placebo), muss es für jedes Schreibmuster auf der Karte funktionieren. Das Problem was man bei FAT ursprünglich hatte: es gab nur eine FAT, wenn die zerstört war, war kaum noch eine Rettung der Daten möglich. Da sind andere FS MEILENWEIT davon entfernt (und trotzdem nimmt man FAT).
Andreas S. schrieb: > Piter K. schrieb: >> dir ist aber schon klar, daß das physische SDHC interface nichts von >> einem filesystem weiß? Dort werden nur Datenblöcke geschaufelt, auf >> einer Ebene noch tiefer als ein Block device. KEINE Spur von >> irgendwelchen Filesystem-relevanten Befehlen etc. > > Selbstverständlich weiß ich das. Und genau darin besteht ja das große > Problem: die Kartenfirmware muss ein Wear Leveling durchführen, da die > "normalen" Dateisysteme so etwas nicht berücksichtigen, und dabei muss > die Kartenfirmware irgendwelche Annahmen treffen. > ganz einfach: die Karte verwaltet die "Abnutzung" der einzelnen Flash Blöcke unabhängig von irgendwelchen FS Sachen. Dazu reicht je ein write count per Block und eine logische-zu-physische Umleitungstabelle (am Anfang 1:1). Diese Tabelle sollte auf eine zugriffsfeste Weise gespeichert werden (entweder mit hoher Redundanz im Flash selbst oder im kleinen eeprom).
Andreas S. schrieb: > Dann hast Du keine Vorstellung davon, welche Leute häufig in > Standardisierungsgremien sitzen. Techniker mit wirklich fundiertem > Wissen findet man dort nur äußerst selten, stattdessen zum einen > profilierungssüchtige Bürokraten ohne relevanten Sachverstand oder auf > das Abstellgleis abgeschobene Entwickler. Die letztgenannten dominieren > dann, wenn es z.B. öffentliche Gelder für die Teilnahme an den Sitzungen > solcher Gremien gibt. Je weniger dabei herauskommt, desto mehr Sitzungen > muss man veranstalten, wodurch man die Nieten hervorragend > durchgefüttert bekommt und sich die ganze Sache rechnet. Doch, eine Vorstellung habe ich schon. Komme aus der Netzwerk-Ecke, wo solche Gremien öfter mal was verbocken (siehe WEP, siehe WPA, etc etc). Trotzdem sind nicht alle IEEE Sachen schlecht. Man lernt oft aus Fehlern (die oft auch nicht notwendig gewesen sind).
Piter K. schrieb: > Das Problem was man bei FAT ursprünglich hatte: es gab nur eine FAT, > wenn die zerstört war, war kaum noch eine Rettung der Daten möglich. Unfug. Schon MS-DOS hatte eine zweite Kopie der FAT auf dem Datenträger. Piter K. schrieb: > ganz einfach: die Karte verwaltet die "Abnutzung" der einzelnen Flash > Blöcke unabhängig von irgendwelchen FS Sachen. Das glaubst du und es ist falsch. Wenn in der Spec zudem steht, dass eine Karte so und so zu formatieren ist, dann gilt implizit auch, dass die Spec nicht mehr zuständig ist, wenn die Karte nicht so formatiert ist. Aber argumentiere du nur weiter. Baldrian trollt sowieso nur rum.
S. R. schrieb: > Baldrian trollt sowieso nur rum. Getroffene Hunde bellen. Danke für deine Rückmeldung. Du bist natürlich im Unrecht.
Kam von dir irgendwas sinnvolles, außer - "glaube ich nicht" - "NDA-Aussagen sind substanzlos" - "beweise deine Aussage" - "Quellen würde ich auch sehen wollen"? Nein. Ergo: Troll. Ständig rumzweifeln ist ja ganz gut, aber irgendwann reicht's dann doch. Was hättest du denn gern? Wärst du mit dem Quelltext einer üblichen SD-Kartenfirmware zufrieden? Den kannst du dir selbst auslesen, Anleitungen gibt's u.a. bei bunnie. Reicht dir aber sicherlich auch nicht. Kann man es euch recht machen oder mosert ihr nur rum, weil's Spaß macht?
S. R. schrieb: > Kam von dir irgendwas sinnvolles, außer > - "glaube ich nicht" > - "NDA-Aussagen sind substanzlos" > - "beweise deine Aussage" > - "Quellen würde ich auch sehen wollen"? Was hast du gegen Belege, Beweise, Quelle. Links, Studien? > Nein. Ergo: Troll. Nein, kein Troll, nur wissbegierig. > Ständig rumzweifeln ist ja ganz gut, aber irgendwann reicht's dann doch. Du brauchst dich nicht so zu echauffieren - ignoriere mich einfach.
Baldrian schrieb: > Was hast du gegen Belege, Beweise, Quelle. Links, Studien? Ich habe geliefert, und du moserst rum. Liefer doch mal selbst.
S. R. schrieb: > Baldrian schrieb: >> Was hast du gegen Belege, Beweise, Quelle. Links, Studien? > > Ich habe geliefert, und du moserst rum. Du meinst sicherlich meine ruhige sachliche Kritik und kannst es nur nicht zum Ausdruck bringen. Ansonsten: Hier ist jetzt Schluss für mich, da nichts sinnvolles zum Thema zu erwarten ist.
S. R. schrieb: > Was hättest du denn gern? Wärst du mit dem Quelltext einer üblichen > SD-Kartenfirmware zufrieden? Den kannst du dir selbst auslesen, ich wäre damit zumindest zufrieden. Würde mich brennend interessieren, was für ein magischer "FAT FS follower" in der Firmware vorhanden sein soll. Ich kann mir nämlich nicht vorstellen, daß dort FS-bezogen viel mehr drin ist, als die vermutete FAT mehrfach redundant zu speichern. Und das wear leveling muss auch für die Datenblöcke außerhalb der FAT funktionieren (falls es überhaupt implementiert ist).
Piter K. schrieb: > ich wäre damit zumindest zufrieden. Würde mich brennend interessieren, > was für ein magischer "FAT FS follower" in der Firmware vorhanden sein > soll. In dem Quelltext, den du von Hyperstone bekommst, ist natürlich nur das Standardgerüst. Welche Firmware gut und welche nicht so gut ist, entscheidet das, was der jeweilige Hersteller dazuprogrammiert. Und diesen Teil des Quellcodes bekommst du eben nicht. Insofern wirst du unwissend weiterleben. Aber mach es doch so wie ich: gehe auf ein paar größere Messen und löchere die Leute dort. Mit passenden Reizworten bekommst du immer wieder ein Häppchen Information. Die andere Möglichkeit ist, als Firmwareprogrammierer bei einem Kartenhersteller anzufangen. Und dann nach und nach die ganzen Hersteller durchzumachen...
:
Bearbeitet durch Moderator
Baldrian schrieb: > Du meinst sicherlich meine ruhige sachliche Kritik und kannst es nur > nicht zum Ausdruck bringen. Naja, "nein" und "glaub ich nicht" sind zwar ruhig, aber keine sachliche Kritik. Tut mir Leid. Piter K. schrieb: > Ich kann mir nämlich nicht vorstellen, daß dort FS-bezogen viel mehr > drin ist, als die vermutete FAT mehrfach redundant zu speichern. Beispiele wurden genannt: - zusätzliches Wear Levelling - zuverlässige(re) Flashblöcke / bessere Checksums - usw. Bei bunnie auf dem Congress gab's Anleitungen, wie du bestimmte SD-Controller (meist 8051) auslesen und neu bespielen kannst. Such dir einfach eine solche Karte und lies die aus. Ich vermute einfach mal, dass es entsprechende Dumps auch gibt. An die originalen Sourcen wirst du nicht rankommen, die sind ziemlich sicher unter Verschluss und NDA; siehe auch Andreas und Lothars Kommentare dazu. Piter K. schrieb: > Und das wear leveling muss auch für die Datenblöcke > außerhalb der FAT funktionieren Aber nicht unbedingt mit gleicher Qualität. Du kannst dich ja, wenn du Lust hast, gerne mal mit f2fs (Samsung's Flash-Friendly Filesystem) befassen, das zielt nämlich darauf ab, gebrauchbar auf SD-Karten (oder eMMC) zu funktionieren.
S. R. schrieb: > Piter K. schrieb: >> Und das wear leveling muss auch für die Datenblöcke >> außerhalb der FAT funktionieren > > Aber nicht unbedingt mit gleicher Qualität. ja eben doch... die SD Karte kann auch bei FAT von keinem bestimmten use case ausgehen. Wie mein Beispiel oben. Wieso sollte bei FAT auf Verwaltungsinformationen öfter geschrieben werden als auf das File selbst? Generell ist das einfach nicht wahr. Beispiel: Überwachungskammera. Bei einer Hikvision die ich habe, werden eine Menge Files fester Größe angelegt und es wird nichts mehr an der Dateistruktur geändert, es wird der Reihe nach auf die Files geschrieben.
Piter K. schrieb: > und es wird nichts mehr an der Dateistruktur geändert Wie kommen dann Informationen wie "zuletzt geändert" o.ä. zustande? > Bei einer Hikvision die ich habe, werden eine Menge Files fester Größe > angelegt und es wird nichts mehr an der Dateistruktur geändert, es wird > der Reihe nach auf die Files geschrieben. Das ist eine alte Strategie, die früher(tm) mal funktioniert hat (und bei dieser Kamera evtl. noch immer funktioniert). Aber andere Rechner protokollieren eben irgendwie jede Änderung auch in der Dateiverwaltung.
SDHC Speicherkarte, 8GB, Class 10, original Hersteller unbekannt. In einem BananaPI hat obige Karte auch keine 3 Wochen überlebt. In der Zeit inkl. noch Versand an mich. Pause ... Image Schreiben und dann lief er so ohne Aufgaben vor sich hin. Dauertest ohne Aufgaben. War "nur" online, damit ich per ssh rauf komme. Nur mal hier und da geschaut um Erfahrungen zu sammeln.
Ich habe eine 32GB-SD-Karte von Transcent für den Raspi formatiert und die Software drauf gespielt. Nach zweimaligen kurzem Gebrauch, das Teil in die Panasonik-Digitalkamera gestöpselt. Nach ein paar Bildern war der Speicher voll, es viel schon auf, daß das Abspeichern der Bilder in der Kamera sehr lange dauerte. Bilder kopiert und dann der völlig erfolglose Versuch, die Daten zu löschen, die Karte zu formatieren. Auch nicht mit irgendwelchen Anleitungen und Tools. Das Teil kann ich wohl iTk in die Tonne krachen ;-((
alsGasthier schrieb: > Ich habe eine 32GB-SD-Karte von Transcent für den Raspi formatiert und > die Software drauf gespielt. Nach zweimaligen kurzem Gebrauch, das Teil > in die Panasonik-Digitalkamera gestöpselt. Im "Standard"-Raspberry-Format sind 2 Partitionen auf der Karte, eine (sehr) kleine FAT-Partition, der Rest Typ "ext4". Siehe auch https://github.com/raspberrypi/noobs/wiki/Standalone-partitioning-explained - Das würde zum Symptom (nur 2 Bilder) passen. Wie hast Du die Karte neu formatiert? Welches Betriebssystem? oder in der Kamera? Hier würde ich empfehlen, das Programm SD Card Formatter "https://www.sdcard.org/downloads/formatter_4/"; zu nutzen, damit wieder die komplette Kapazität für die Kamera zur Verfügung steht.
:
Bearbeitet durch User
Lothar M. schrieb: >> Bei einer Hikvision die ich habe, werden eine Menge Files fester Größe >> angelegt und es wird nichts mehr an der Dateistruktur geändert, es wird >> der Reihe nach auf die Files geschrieben. > Das ist eine alte Strategie, die früher(tm) mal funktioniert hat (und > bei dieser Kamera evtl. noch immer funktioniert). Aber andere Rechner > protokollieren eben irgendwie jede Änderung auch in der > Dateiverwaltung. Das ist eben ein Trugschluss... beispiel mount option "lazytime" unter Linux.
1 | lazytime |
2 | Only update times (atime, mtime, ctime) on the in-memory version of the file inode. |
3 | |
4 | This mount option significantly reduces writes to the inode table for workloads that perform frequent random writes to preallocated files. |
5 | |
6 | The on-disk timestamps are updated only when: |
7 | |
8 | - the inode needs to be updated for some change unrelated to file timestamps |
9 | |
10 | - the application employs fsync(2), syncfs(2), or sync(2) |
11 | |
12 | - an undeleted inode is evicted from memory |
13 | |
14 | - more than 24 hours have passed since the i-node was written to disk. |
Es gibt 1001+ valide und gebräuchliche Szenarien, wo nur in das File geschrieben wird, aber nichts an der eigentlichen Struktur des FS geändert wird. Je nach FS und den mount options (oder je nach Gerät... wer sagt daß eine China-Cam den Timestamp selbst bei FAT aktualisiert?! vielleicht war man so "sparsam" und schreibt nur die EXIF Daten mit time stamp aber keinen timestamp in die FAT? alles schon erlebt... eventuell hat das Gerät überhaupt keine Ahnung von Zeit und kann so überhaupt keine Zeitstempel schreiben?) Wie gesagt ich halte das für Esoterik, wenn eine Optimierung in der FW der Karte stattfinden soll speziell für die FAT Metadaten. Deshalb bleibe ich bei der Vorstellung ein BRAUCHBARES WL jenseits von Esoterik muss die ganze Karte berücksichtigen, unabhängig von FS. Wenn jetzt zusätzlich noch eine Art Heuristik implementiert ist, die speziell für FAT die angenommenen "wichtigen" Blöcke extra-doppelt-super-sicher speichert, dann tut das auch nicht weh, wenn kein FAT drauf ist.
:
Bearbeitet durch User
Ich empfehle einen Blick auf die Seite hinter dem von Thomas aufgeführten Link: https://www.sdcard.org/downloads/formatter_4/ Dort steht: > The SD Card Formatter formats SD Memory Card, SDHC Memory Card and > SDXC Memory Card (respectively SD/SDHC/SDXC Cards) complying with > the SD File System Specification created by the SD Association (SDA). Abweichend von Piters Behauptung legt die SD Association offenbar doch das/die zulässige(n) Dateisystem(e) fest. > It is strongly recommended to use the SD Card Formatter to format > SD/SDHC/SDXC Cards rather than using formatting tools provided with > individual operating systems. Aha! > In general, formatting tools provided > with operating systems can format various storage media including > SD/SDHC/SDXC Cards, but it may not be optimized for SD/SDHC/SDXC Cards > and it may result in lower performance. "Lower performance" bedeutet in solch einem Zusammenhang nicht unbedingt die Übertragungsgeschwindigkeit, sondern beliebige Leistungsmerkmale. Und dazu gehört z.B. auch die Haltbarkeit der Daten. > SD/SDHC/SDXC Cards have a “Protected Area” for SD Card security > purposes. The SD Card Formatter does not format the protected area in > the SD/SDHC/SDXC Cards. The protected area shall be formatted by an > appropriate PC application or SD host devices that provide SD security > function. Also Finger weg von der geschützten Bereichen! Wenn ein Datenträger z.B. per "Schnellformatierung" formatiert wird, fällt es unter Umständen anfangs gar nicht auf, dass hierbei auch solch ein geschützter Bereich zur Verfügung gestellt wird. Erst beim Beschreiben der entsprechenden Blöcke kracht es dann. > The SD Card Formatter doesn't support SD/SDHC/SDXC Card encrypted by > the “BitLocker To Go" functionality of Windows. Please format the > SD/SDHC/SDXC Card after it has been unlocked. Klar, Bitlocker befindet sich auf einer ganz anderen Abstraktionsebene und hat überhaupt nichts mit SD zu tun.
Piter K. schrieb: > Lothar M. schrieb: >> Aber andere Rechner protokollieren eben irgendwie jede Änderung >> auch in der Dateiverwaltung. > > Das ist eben ein Trugschluss... beispiel mount option "lazytime" unter > Linux. Natürlich ist es möglich, mit solchen Optionen zu arbeiten, zumindest wenn die betreffende Kernelversion und zugehörigen Dienstprogramme es unterstützen. Bei einem vorkonfektionierten Gerät bedeutet es aber, dass der betreffende Entwickler diese Option oder z.B. "noatime" gesetzt hat, was aber nicht zwingend der Fall gewesen sein muss. Natürlich kann man als versierter Entwickler/Bastler auch in solch ein Gerät eindringen und die Optionen kontrollieren, aber dieser Weg wird von maximal 0,1% aller Benutzer/Besitzer gewählt. Und in vielen Fällen sind auch linuxbasierte Geräte so weit zugenagelt, dass der Aufwand für einen Eingriff viel zu hoch wäre. Und dann gibt es auch noch Unmengen an Betriebssystemen, die entweder erst gar nicht quelloffen sind oder mit der Anwendung statisch kompiliert sind und gar keine Modifikationen zulassen.
Hallo, habe das gelesen: https://www.sdcard.org/downloads/formatter_4/SD_CardFormatter5UserManualEN_v0100.pdf und den Post hierüber. Aber wie soll denn dann bitte ein "normaler" User dann ein Linux auf die Karte bekommen? Ich kenne nur fertige Images, die direkt als Image auf die Karten geschrieben werden. Da hab ich doch gar keine Chance am Filesystem etwas zu ändern und weiß auch nicht, was der Imagewriter da tut. Vielen Dank an ALLE, die hier etwas Aufklärungsarbeit geleistet haben und noch tun.
Andreas S. schrieb: >> In general, formatting tools provided >> with operating systems can format various storage media including >> SD/SDHC/SDXC Cards, but it may not be optimized for SD/SDHC/SDXC Cards >> and it may result in lower performance. > > "Lower performance" bedeutet in solch einem Zusammenhang nicht unbedingt > die Übertragungsgeschwindigkeit, sondern beliebige Leistungsmerkmale. > Und dazu gehört z.B. auch die Haltbarkeit der Daten. wobei ich mich schon wieder wiederholen muss: es macht keinen Sinn irgendwelche FAT metadaten besonders sicher zu speichern, wenn man es nicht genauso tut für den Rest der Daten. Wenn ich immer wieder in das eine File schreibe, wird metadata + file genauso oft beschrieben.
Banane schrieb: > Aber wie soll denn dann bitte ein "normaler" User dann ein Linux auf die > Karte bekommen? > Ich kenne nur fertige Images, die direkt als Image auf die Karten > geschrieben werden. Da hab ich doch gar keine Chance am Filesystem etwas > zu ändern Das ist ein Zaunpfahl, dass diese Karten nicht dafür konstruiert sind, als beschreibbares root fs in einem Linux etc eingesetzt zu werden. fchk
Piter K. schrieb: > es macht keinen Sinn > irgendwelche FAT metadaten besonders sicher zu speichern, Wann soll ich derartiges behauptet haben?
Andreas S. schrieb: > Piter K. schrieb: >> Das ist ja OK. Aber die Behauptung ein anderes FS als FAT würde die >> Karte ruinieren kann einfach nicht wahr sein. > > Die Praxis zeigt doch aber genau dieses Verhalten, d.h. Karten mit > abweichender Formatierung sind teilweise wesentlich unzuverlässiger. Das wird vielleicht so empfunden, kann sich in der Praxis aber wirklich nur auf die trivialen use cases beziehen. Sprich, die meisten SD Karten werden in DCams, Smartphones & co zum Speichern von Bildern und Multimedia genutzt, d.h. hier liegt tatsächlich der von dir postulierte Fall vor, daß bestimmte Blöcke öfter beansprucht werden als andere. Das hat aber wirklich NICHTS mit dem Filesystem zu tun. Oder anderes herum formuliert: Karten die NICHT mit FAT formatiert sind, haben in der Praxis ein anderes write pattern als Karten mit FAT, woraus aber NICHT folgt, daß ein solches write pattern mit FAT grundsätzlich nicht möglich ist. => falscher Umkehrschluß. Deshalb auch meine Anmerkung, daß eine ordentliche SD Karte sein wear lvling nicht starr auf eine angenommene FS Nutzung ausrichten sollte und darf... > Bei FAT und allen anderen nicht auf Flash optimierten Dateisystemen > besteht das grundlegende Problem, dass einige Sektoren/Blöcke bei > Schreibvorgängen sehr stark belastet werden und andere weniger, nämlich > wegen der Unzahl an Metaoperationen. Bei Flash ist auch nicht das > Schreiben der zerstörende Vorgang, sondern das Löschen von Blöcken. => Bezug zum vorletzten Post.
Blablabla... SD-Karten sind primär für die Datenaufzeichnung und den Transport von uns zu Mobilgeräten bestimmt. Zumindest war dies das Entwurfsziel. Deswegen wurden auch keine Dateisysteme definiert oder berücksichtigt, die auf die Besonderheiten von Flash-Speicher ausgerichtet sind. SD-Karten sind keine "ordentlichen" Speichermedien für den universellen Einsatz. Sie sind einfach nur billig, klein und einfach per SPI anzusteuern. Nur deswegen werden sie so häufig zwecksentfremdet. Für mich ist diese Diskussion jetzt beendet.
:
Bearbeitet durch User
Andreas S. schrieb: > Blablabla... SD-Karten sind primär für die Datenaufzeichnung und den > Transport von uns zu Mobilgeräten bestimmt. Zumindest war dies das > Entwurfsziel. Deswegen wurden auch keine Dateisysteme definiert oder > berücksichtigt, die auf die Besonderheiten von Flash-Speicher > ausgerichtet sind. Wobei das FAT als das ungeeignetste besonders berücksichtigt wurde ;)
Piter K. schrieb: > Deshalb auch meine Anmerkung, daß eine ordentliche SD Karte sein wear > lvling nicht starr auf eine angenommene FS Nutzung ausrichten sollte und > darf... In der Realität aber ist. Dass ein solches Verhalten standardkonform ist, wurde bewiesen. Dass ein solches Verhalten real auftritt, wurde untermauert. Du laberst. Ich bin raus.
Thread beobachten
Seitenaufteilung abschalten
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.