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.
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?
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.
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.
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
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.
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.
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 ;)
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?
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.
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.
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.
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.
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...
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.
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...
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.
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.
> 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.
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....
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.
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!
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.
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.
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
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?
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.
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.
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.
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.
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...
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.
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.
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
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.
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
