mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik MIcroSD Karte durch Raspberry PI zerstört


Autor: Piter Kura (kurczaq)
Datum:

Bewertung
-6 lesenswert
nicht lesenswert
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.

Autor: Jim Meba (turboj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: H. E. (hobby_elektroniker)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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.

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Nun ich habe erstmal die Marke gewechselt zu Sandisk. Mal sehen.

Für mich ist das bad engineering was Kingston da macht.

Autor: c.m. (Gast)
Datum:

Bewertung
4 lesenswert
nicht lesenswert
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)"

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
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....

Autor: Jim Meba (turboj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: GeraldB (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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/

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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.

Autor: Isunit (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
> 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

Autor: Martin Schlüter (led_martin)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jim Meba (turboj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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?

Autor: batman (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Kannst du denn den Sektor 0 nicht neu schreiben oder löschen - bevor das 
OS da mit den Resten evt. etwas anzumelden versucht?

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Andreas B. (andreasb)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: batman (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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..

Autor: oszi40 (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: qx (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
An einem Raspberry PI 1 habe ich das auch schon an einer SD-Karte von 
Sandisk gehabt. Datenträger hat 0 Byte Größe

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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).

Autor: Walter Tarpan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Brummbär (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Piter K. schrieb:
> Dann verliert man die Daten aber
> nicht gleich die Karte :/

Das wäre aber ökonomisch äußerst ineffektiv.

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Walter Tarpan (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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 :)

Autor: Plattenputzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mikro 77 (mikro77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Oliver R. (superberti)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Conny G. (conny_g)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Piter K. schrieb:
> Für mich ist das bad engineering was Kingston da macht.

Billiges Produkt = Bad Engineering, das ist immer so.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: AntiMaker (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: batman (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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.

Autor: Mikro 77 (mikro77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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, ... ?

Autor: H. E. (hobby_elektroniker)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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" :)

Autor: solder (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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://r...

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: GeraldB (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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/

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Christian B. (luckyfu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Thomas O. schrieb:
> Under warranty we can only offer you a like for like replacement.

Das bedeutet: Wenn du noch garantie hast bekommst du ein ähnliches 
Gerät, weils das gleich nicht mehr gibt.

: Bearbeitet durch User
Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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?

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :/

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: soul eye (souleye)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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 ;)

Autor: Mikro 77 (mikro77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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").

Autor: batman (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: Baldrian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)?

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/...

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.

Autor: soul eye (souleye)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Baldrian (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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 ;)

Autor: batman (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Bei einer geschätzten mittleren Produktlebensdauer von 30 Tagen pro 
FW-Version auch ein ziemlich sinnloses Unterfangen.

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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?

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Ich fasse das bisherige zusammen:

Kingston MicroSD Karten sind unter den Vorgaben aus der BWL-Abteilung 
entwickelt worden ;)

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier noch was direkt von Kingston:

https://media.kingston.com/pdfs/MKF_283.1_Flash_Me...

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?

Autor: batman (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei einem anderen PI läuft eine EVO schon seit einem Jahr und der 
rebootet täglich über cron... und noch nichts ausgefallen.

Beitrag #5076222 wurde von einem Moderator gelöscht.
Autor: Piter Kura (kurczaq)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Jim Meba (turboj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Hp M. (nachtmix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ü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).

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So mal als ASCII Art:
        -------------------
 ------/      |     =      |
|=            |     =      | <--- Karte hier
|=  STECKER   |SLOT =      |
|=            |            |
 -------------|------------
              | CAP  | D   |
               ------------
<------------>
verschwindet
 im RPI


Autor: Peter (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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?

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
@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.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Mikro 7. schrieb:
>> oder die Karte gar nicht mehr erkannt wird.
> Das wäre eine neue Dimension. Wie identifzierst du das? Ungültiges SPI
> Packet, Error Response, Initialisierung, ... ?
Ich stecke sie an verschiedene Geräte und schaue, was die damit 
anfangen. Wenn z.B. ein Windows Rechner nichts mehr mit der Karte 
anfangen kann und nichtmal das SMART Tool des Herstellers auf die Karte 
kommt, dann ist das Ding für mich defekt.

Peter schrieb:
> Bisher hat nur Lothar sich mit seinen Erkenntnissen aus eigenen Tests zu
> Wort gemeldet.
Diese Tests umfassen ca. 70 Karten mehrerer Hersteller. Die untauglichen 
Karten sind nach 1-2 Wochen defekt. Die Besten halten über 40 Wochen. 
Bei diesen verläuft der Test natürlich eher "zäh"... 😉

Peter schrieb:
> Aber wer kann beweisen, dass seine Karte ausgefallen ist weil der
> Flash-Controller wegen Stromausfall oder Ähnlichem die Hufe hoch
> gerissen hat und es nicht einfach die normale
> Sterblichkeitswahrscheinlichkeit war?
Wer schlechte Karten hat, bekommt das problemlos hin. Ich habe diese 
langjährigen Tests nur deshalb begonnen, weil aus der "Prototypserie" 
mit TLC Flash Fehler gemeldet wurden. Und das schon wenige Wochen nach 
Auslieferung der ersten Maschinen.

Und zum Glück habe ich dann mit Samsung recht gute Consumer-Karten 
gefunden, und bin jetzt mit den Glyn MLC Karten sehr zufrieden.

Kingston waren wegen des "guten Namens" übrigens die zweiten, die ich 
ausprobiert habe. Der Test war recht kurz...

Piter K. schrieb:
> Shottky
Walter hieß Schottky.

: Bearbeitet durch Moderator
Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: J. Wa. (nuernberger)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man sollte regelmäßig ein Backup machen. Das geht so:
https://www.raspberrypi.org/forums/viewtopic.php?f...

Ich selber verwende 32G Sandisk und hatte noch keine Ausfälle trotz 
intensiver Benutzung.

Autor: batman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und meine erste defekte war ne Sandisk.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Peter schrieb:
> Aber wer kann beweisen, dass seine Karte ausgefallen ist weil der
> Flash-Controller wegen Stromausfall oder Ähnlichem die Hufe hoch
> gerissen hat und es nicht einfach die normale
> Sterblichkeitswahrscheinlichkeit war?
Das lustige an der Sache ist übrigens, dass es gar nicht sooooo arg 
viele Flash-Hersteller gibt. Und deshalb mit hoher Wahrscheinlichkeit in 
gleichzeitig am Markt verfügbaren Karten das (annähernd) selbe Flash 
verbaut ist. Ob eine Karte also 2 oder 40 Wochen durchhält, liegt dann 
sehr stark in der Firmware und im Wearleveling.

Und genau so habe ich das beobachtet: microSD eines Herstellers X mit 
der Firmware A waren nach 2..3 Wochen kaputt. Nach Analyse durch den 
Hersteller X (das hat mich beeindruckt, Hersteller K z.B. ließ nur von 
sich hören, die Karten seien eben defekt) stellte der den Algorithmus um 
und die (selben!!) Karten laufen jetzt ein dreiviertel Jahr ohne 
Probleme.

Und so ist es lustigerweise auch bei den anderen Karten: ein Hersteller 
verwendet "sein" Firmwarekonzept für alle seine Karten. Und deshalb ist 
es für mich wenig überraschend, dass alle 4 unterschiedlichen von mir 
getesteten Samsung-Karten sehr gute Ergebnisse liefern. Und 3 
unterschiedliche Kingston-Karten eben eher schlechte...

J. W. schrieb:
> Ich selber verwende 32G Sandisk und hatte noch keine Ausfälle trotz
> intensiver Benutzung.
Ich kann zu einer (relativ teuren) SDSDQM-008G nur sagen, dass sie eine 
der schlechtesten im Test war. Weitere Karten von Sandisk habe ich dann 
gleich gar nicht getestet...

: Bearbeitet durch Moderator
Autor: Mikro 77 (mikro77)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Mikro 77 (mikro77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.)

Autor: soul eye (souleye)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Mikro 7. schrieb:
> Hast du eine Möglichkeit gefunden, die guten von den schlechten Karten
> (vorweg) zu identifizieren?
Jein.
Die ganz schlechten sind die Consumer-Karten, die kaum die Bilder vom 
letzten Urlaub behalten können... ;-)

soul e. schrieb:
> Da hast Du dann schonmal 150 GB unformatierte Kapazität in einer 64
> GB-Karte. Die kaputten Blöcke sind ausgeblendet und für den User nicht
> sichtbar.
Einer der "Tricks" zur "Langlebigkeit" ist der, in eine industrielle 8GB 
Karte ein billiges 32GB Flash zu bauen. Dann hat man sogar ohne 
ausgeschlafenes Wearleverling schon mal die vierfache "Lebensdauer"...

S. R. schrieb:
> Mir war bekannt, dass ein Stromausfall auf einer SD-Karte beliebige
> Blöcke zerstören kann
Ein anderer Test war, auf eine "volle" Karte in eine Logdatei laufend 
noch ein zusätzliches Byte zu kopieren, dann muss die Karte quasi 
laufend "umsortiert" werden. Die Karte war dauernd unter Strom und 
trotzdem waren nach gewisser Zeit (2 Mio ... 200 Mio Kopiervorgänge je 
nach Hersteller) Daten korrupt, die nie angefasst, sondern nur gelesen 
wurden. Solche korrupten Daten zeugten dann (gern auch zusammen mit 
einem "langsamer Werden") vom baldigen Ende der Karte.

: Bearbeitet durch Moderator
Autor: Conny G. (conny_g)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Baldrian (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: soul eye (souleye)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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...

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
soul e. schrieb:
> Das gilt für jeden Typ von NAND-Flash.
Das gilt sogar für NOR-Flash.

> wenn Du sie einmal im Jahr an Strom hängst und den Controller seine
> Zellenprüfung machen lässt.
Da habe ich auch noch einen Test am Laufen: ich hatte mit 2 Karten einen 
Test begonnen, brauchte aber nach 1 Woche die Prüfplätze für andere 
Karten. Also die beiden Karten herausgenommen und sicher eingelagert. 
Die Unterbrechung dauerte knapp ein halbes Jahr. Dann wollte ich die 
beiden zwischengelagerten microSD weitertesten, und böse Überraschung: 
beide waren nicht mehr ansprechbar. Eine wurde gar nicht mehr erkannt, 
die andere meldete sich mit Hieroglyphen...

S. R. schrieb:
> Jemand hat dazu mal sinngemäß gesagt: "Flash speichert nicht deine
> Daten, Flash speichert nur eine statistische Approximation deiner Daten."
Ja, wenn pro Zelle 3 Bit gespeichert werden (= 8 verschiedene Zustände), 
dann ist das reinste Analogtechnik...

: Bearbeitet durch Moderator
Autor: Personalvorstand a.D. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Stefan Us (stefanus)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
> 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.

Autor: AntiMaker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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"

Autor: Mikro 77 (mikro77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Stefan Us (stefanus)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
> 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.

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
http://elinux.org/RPi_SD_cards

hier noch was gefunden.... ein Bild des Grauens!

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: René F. (therfd)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: soul eye (souleye)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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
Reservierte Sektoren

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).

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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 ;)

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
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:
4.13.2.7.3 Requirements of SD File System

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.
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.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
soul e. schrieb:
> Die entsprechenden Dokumente unterliegen NDAs und sind daher nicht
> öffentlich zugänglich.
Du musst für Auskünfte auf der Messe den FAE oder einen, der der 
Entwicklung nahesteht in einer schwachen Minute erwischen. Auskünfte 
über Interna gibt es gar nicht. Nicht mal über NDA.

Eine Frage, die ich schon Anfang des Jahrtausends bezüglich CF Karten 
gestellt habe, war einfach:
Wie lange muss die Karte nach dem letzten Schreibbefehl noch mit 
Spannung versorgt werden, dass sie mit internen Verwaltungsaufgaben 
fertig ist und die Finger vom Flash lässt?
Resultat nach monatelanger Fragerei: die Karten werden aufgemacht, ein 
paar Drähte ans Flash gelötet und der Logikanalyser angeschlossen.

Und erst auf die Frage, was denn da knapp 700ms nach dem Schreibbefehl 
noch am Flash passiere, und ob diese Zeit noch schlimmer sein könnte, 
bekam ich die Antwort, dass die Karte noch für 1s gepuffert werden 
sollte.

: Bearbeitet durch Moderator
Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
S. R. schrieb:

>
> 4.13.2.7.3 Requirements of SD File System
> 
> 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.
> 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.
> 

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.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Piter K. schrieb:
> CAN BE APPLIED ONLY TO...
> des Englischen mächtig?

Es ist vollkommen egal, was man schreibt, du glaubst es ja doch nicht.

Autor: Mikro 77 (mikro77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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....

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier noch mal der Link, falls er untergegangen ist:

http://elinux.org/RPi_SD_cards#Working_.2F_Non-wor...

Samsung, Lexar, Toshiba, Sony weniger problematisch als der Rest.

Autor: Mikro 77 (mikro77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Piter K. schrieb:
> 2.0   SSD, Flash Card and USB Flash Drive Capacity
> Some of a Flash storage device’s listed capacity is used for formatting
> and other functions and thus is not available
> for data storage.

Was verstehst Du an "other functions" nicht?

> When a Flash storage device is designed and manufactured, steps are
> taken to ensure that the device operates
> reliably and to permit the host device (computer, digital camera,
> tablets, mobile phone, etc.) to access the memory
> cells — i.e., to store and retrieve data on the Flash storage device.
> Formatting includes the following operations:

Da steht doch "manufactured" und "Formatting". Das ist so zu lesen, dass 
die Formatierung während der Herstellung erfolgt. Für den späteren 
Gebrauch sind die Anwendungsfälle "store data" und "retrieve data" 
definiert, d.h. Dateizugriffe gemäß für den vorkonfigurierten 
Dateisystemtyp üblichen Konventionen. Dass hierbei keine beliebige 
Operationen auf Sektorebene gemeint sind, folgt dann wiederum aus der 
SD-Spezifikation.

> <Punkte 1 bis 5>

Dort ist explizit aufgeführt, welche Schritte während der Herstellung 
erfolgen, und dazu gehört insbesondere auch Punkt 4: "Creating a File 
Allocation Table (FAT) or other directory."

> 6.   Where applicable, reserving some cells for special features. For
> example, the specification for Secure Digital (SD)
> cards requires reserved areas to support special copy protection and
> security features.

Die Karten können also Sektoren, Blöcke o.ä. enthalten, die 
Sonderfunktionen bewirken. Erzeugt man also sein eigenes Dateisystem, 
können dadurch auch solche reservierten Blöcke zwecksentfremdet werden, 
was beliebige ulkige Auswirkungen haben kann.

> => es wird nicht behauptet FAT ist irgendwie obligatorisch....

Es wird ganz klar gesagt, dass die Formatierung und damit die Festlegung 
des Dateisystemtyps während der Herstellung erfolgt und zu keinem 
anderen Zeitpunkt.

Die Zweckentfremdung von Block Devices und entsprechender 
Pseudodateisysteme ist übrigens auch bei ganz anderen Anwendungen 
üblich.

Manche USB-Geräte melden sich als Mass Storage und stellen sogar ein 
FAT-Dateisystem bereit. Dieses ist aber ggf. überhaupt nicht mit Flash 
oder RAM-Disk o.ä. hinterlegt, sondern wird von der Gerätefirmware nur 
simuliert. Wer nun versucht, solch ein Gerät zu formatieren, wird auch 
seine Überraschung erleben. Im einfachsten Fall passiert einfach gar 
nichts und die alte Struktur bleibt erhalten. Ansonsten stürzt ggf. die 
Firmware ab.

Ein weiteres sehr großes Anwendungsfeld für derartige zweckentfremdete 
Block Devices sind große Speichergeräte, d.h. RAID-Systeme bzw. SAN. Bei 
EMC werden sie als sog. "Gatekeeper Device" bezeichnet. Die 
Konfiguration solcher Speichergeräte erfolgt also nicht etwa über 
entsprechende SCSI/Fibrechannel-Konfigurationskommandos, sondern durch 
Schreibzugriffe auf das Gatekeeper Device. Der große Vorteil besteht 
darin, dass man keinen speziellen (SCSI-)Gerätetreiber für die 
Konfiguration oder Zugriff auf den "generic"-Treiber (z.B. /dev/sg<n> 
unter Linux) benötigt, sondern nur ein normales Block Device. Man sollte 
sich natürlich auch hier tunlich hüten, solch ein Gatekeeper Device mit 
seinem Lieblingsdateisystem zu formatieren.

: Bearbeitet durch User
Autor: Piter Kura (kurczaq)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: GeraldB (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Mikro 77 (mikro77)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Baldrian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Piter K. schrieb:
> Wenn nun implizit nur ein FAT system vorausgesetzt wird dann ist das ein
> klarer Verstoß gegen jedes OSI Model und sonstige gute
> Designrichtlinien.
Ein Steuergerät eines Autos sollte auch einfach immer das selbe tun. 
Und trotzdem gibt es da welche, die sich an bestimmte Betriebszustände 
anpassen...

Wie ich schon schrieb: in ihrem Drang, ein sicheres Speichermedium zu 
bauen, gehen die Programmierer über die Norm hinaus und versuchen 
herauszufinden, welches FS da werkelt und passen ihr Speichermanagement 
daran an. Und wenn sie nichts herausfinden, dann geht es zurück in den 
Defaultmodus.

Überlege einfach mal, wie du das machen würdest, wenn dein Chef käme 
und zur OSI konformen Implementation sagt: Das muss aber noch besser 
werden!

: Bearbeitet durch Moderator
Autor: Historiker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mikro 77 (mikro77)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Noch ein (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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...

Autor: S. R. (svenska)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Thomas O. (kosmos)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Ich habe mit einer 128GB uSD Karte meines Sohnes Probleme wurde nur als 
exFAT im Kindle Für verwendet. Und hoffe das mir hier aufgrund folgender 
Aussage "And in case of exFAT file system, Allocation Bitmap shall be 
stored in the first 4MB of Cluster Heap." jemand helfen kann.

Könnte mir jemand genau diese ersten 4MB einer 128GB einer Sandisk uSD 
Karte zusenden evtl. per DD ausgelesen.

Die Karte ist lesbar aber nicht mehr beschreibbar. Formatieren sowohl 
unter Debian Linux als auch unter Win7 wird mit einer 
Fertigstellungsmeldung bestätigt. Die Karte wird aber nicht verändert 
erst chkdsk aus der Eingabeaufforderung aufgerufen brache eine 
Fehlermeldung die auf Allocation Bitmap Fehler schließt.

: Bearbeitet durch User
Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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!

Autor: Matthias S. (Firma: matzetronics) (mschoeldgen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Baldrian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: soul eye (souleye)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Ü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?).

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Matthias S. (Firma: matzetronics) (mschoeldgen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Baldrian schrieb:
>> ... eine der wichtigsten Botschaften ist
>> ja, das SD Karten extrem unzuverlässige Datenspeicher sind ...
>
> Nein.
>> ... ein Preiskampf in diesem Segment herrscht, ...
> Ja.
>> ... der jegliche Datensicherheit illusorisch macht.
> Nein.
Schau dir den Vortrag mal an. SD Karten werden grösstenteils aus Schrott 
zusammengebaut. Jegliche Datensicherheit ist nur ein Wunsch des Käufers 
(und du glaubst da anscheinend dran).
Woher nimmst du deinen Glauben? Bist du so ein Hersteller? Wo Preiskampf 
herrscht, bleibt immer die Qualität auf der Strecke. Ob das Airlines 
oder SD Karten Hersteller sind, spielt dabei keine Rolle. Es gibt nur 
eine Handvoll Hersteller, bei denen das manchmal etwas besser ist.

: Bearbeitet durch User
Autor: Piter Kura (kurczaq)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Frank K. (fchk)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Frank K. schrieb:

>> Referenz? Angabe von Quelle und Paragraph bitte.
>
> SD Specifications Part 2 File System Specification Version 3.00

http://read.pudn.com/downloads188/ebook/881633/SD%...

Ist das etwa das hier? (vom LKW gefallen...)

Da steht zwar tatsächlich drin:

https://s23.postimg.org/fjrhjrfi3/sdhc.png

Allerdings vom Sprachgebrauch her, bezieht sich das auf die dort 
vorhandene Tabelle. Es wird zwar "verboten" eine 8GB Karte mit FAT16 
teilzuformatieren etc, heißt aber wiederum:
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.

Autor: Frank K. (fchk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Paul B. (paul_paul)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Paul B. schrieb:
> Samsung SD Karten...
> Kann ich nicht empfehlen
Ja, so gehen die Erfahrungen auseinander....

Hast du zu "wie oft" und "wie viele" und "welche" auch noch Daten? 
Besonders der Kartentyp wäre interessant,  dann würde ich die auch mal 
kaufen und testen. Weil damit dann ja meine Annahme "gleicher Hersteller 
= gleiche Firmware) widerlegt wäre.

Welche Karten würdest du stattdessen empfehlen?

: Bearbeitet durch Moderator
Autor: Piter Kura (kurczaq)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Lothar:

http://elinux.org/RPi_SD_cards

eventuell ist diese Tabelle hilfreich.

Autor: Thomas O. (kosmos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: kartenspiel (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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...

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Piter K. schrieb:
> Das ist ja OK. Aber die Behauptung ein anderes FS als FAT würde die
> Karte ruinieren kann einfach nicht wahr sein.

Die Praxis zeigt doch aber genau dieses Verhalten, d.h. Karten mit 
abweichender Formatierung sind teilweise wesentlich unzuverlässiger.

> Wie ich schon sagte: das
> wear leveling muss funktionieren, EGAL wo auf die Karte geschrieben
> wird.

Das ist die Definition eines perfekten Datenträgers. Leider trifft diese 
Definition nicht auf reale Produkte zu, insbesondere wenn diese auch 
noch allen möglichen anderen Zwängen unterliegen: Platzbedarf, 
Stromversorgung, Kosten.

> Wenn sich eine Anwendung entschließt wild irgendwo mitten in FAT
> Files hineinzuschreiben dann ist das auch nicht anders als wenn ein
> anderes FS drauf ist.

Bei FAT und allen anderen nicht auf Flash optimierten Dateisystemen 
besteht das grundlegende Problem, dass einige Sektoren/Blöcke bei 
Schreibvorgängen sehr stark belastet werden und andere weniger, nämlich 
wegen der Unzahl an Metaoperationen. Bei Flash ist auch nicht das 
Schreiben der zerstörende Vorgang, sondern das Löschen von Blöcken.

Bei "ordentlichen" Flash-Dateisystemen versucht man, die Zahl der 
Löschvorgänge zu minimieren. Es ist durchaus möglich, Speicher in einer 
Richtung zu überschreiben, z.B. nachträglich weitere 1 in 0 zu ändern, 
ohne den Block vorher löschen zu müssen. Dies kann ein Dateisystem 
durchaus ausnutzen, um z.B. Verzeichnis- und Belegungslisten zu 
aktulisieren bzw. auch als "verbraucht" bis zum nächsten Löschvorgang zu 
markieren. Bei Flashzellen mit mehrwertiger Logik kann die Betrachtung 
leider nicht auf Einzelbitebene erfolgen, sondern ggf. auf 
Bitgruppenebene. Bei der Konfiguration von Flash-Dateisystemen wie z.B. 
JFFS2 werden daher etliche Parameter angegeben, z.B. die 
Löschblockgröße. All diese Informationen sind nicht bei normalen 
Speicherkarten verfügbar. Daher muss die Kartenfirmware versuchen, die 
ganzen Vorgänge im Hintergrund zu optimieren, wohlwissend dass jederzeit 
der Strom ausfallen kann.

: Bearbeitet durch User
Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Piter K. schrieb:
> dir ist aber schon klar, daß das physische SDHC interface nichts von
> einem filesystem weiß? Dort werden nur Datenblöcke geschaufelt, auf
> einer Ebene noch tiefer als ein Block device. KEINE Spur von
> irgendwelchen Filesystem-relevanten Befehlen etc.

Selbstverständlich weiß ich das. Und genau darin besteht ja das große 
Problem: die Kartenfirmware muss ein Wear Leveling durchführen, da die 
"normalen" Dateisysteme so etwas nicht berücksichtigen, und dabei muss 
die Kartenfirmware irgendwelche Annahmen treffen.

> Wenn nun implizit nur ein FAT system vorausgesetzt wird dann ist das ein
> klarer Verstoß gegen jedes OSI Model und sonstige gute
> Designrichtlinien.

Die Argumentation mit "jedem OSI Model" ist die völliger Unsinn. Das 
OSI-Modell ist ein Referenzmodell für Netzwerkprotokolle und nicht mehr 
oder weniger. Nicht jedes Schichtenmodell ist an das OSI-Modell 
angelehnt, auch wenn viele Idioten mit gefährlichem Halbwissen dies 
immer wieder behaupten. Nicht einmal TCP/IP entspricht dem OSI-Modell. 
Die Implementierung des OSI-Protokolls auf Basis des OSI-Modells ist 
schon vor langer Zeit gescheitert, da es sich als nicht praktikabel 
erwiesen hat. Dennoch wurden aber auch einige Teilfunktionalitäten in 
andere Netzwerkprotokolle übernommen, z.B. aus X.400 für E-Mails oder 
X.500 für LDAP/Active Directory. Andere Teile findet man noch in der 
Vermittlungstechnik (SS7/Q.700) oder im Bankenbereich, z.B. FTAM. 
Trotzdem handelt es sich eben um keine über alle Schichten durchgängige 
Implementierung des OSI-Modells.

> Und ich kann mir nicht vorstellen, daß ein Gremium
> wie SDcard foundation so einen Mist verzapft. Ganz ehrlich nicht.

Dann hast Du keine Vorstellung davon, welche Leute häufig in 
Standardisierungsgremien sitzen. Techniker mit wirklich fundiertem 
Wissen findet man dort nur äußerst selten, stattdessen zum einen 
profilierungssüchtige Bürokraten ohne relevanten Sachverstand oder auf 
das Abstellgleis abgeschobene Entwickler. Die letztgenannten dominieren 
dann, wenn es z.B. öffentliche Gelder für die Teilnahme an den Sitzungen 
solcher Gremien gibt. Je weniger dabei herauskommt, desto mehr Sitzungen 
muss man veranstalten, wodurch man die Nieten hervorragend 
durchgefüttert bekommt und sich die ganze Sache rechnet.

Die Spezifikationen werden dann von den Heißluftdüsen verfasst, die sich 
dann allerdings im Hintergrund bei fähigen Entwicklern schlau machen. 
Allerdings werden dann wiederum auch wirklich gute technische Konzepte 
wieder umformuliert, damit die Heißluftdüse das ganze als eigenen 
Beitrag darstellen kann.

Sehr viele wichtige Spezifikationen enthalten durchaus schwere 
Entwurfsfehler. Teilweise werden sie in späteren Versionen der 
Spezifikation korrigiert, wobei aber auf strikte Kompatibilität zu 
bestehenden Systemen zu achten ist. Teilweise macht aber auch jeder 
seinen eigenen Workaround, so dass dann im Laufe der Zeit gewisse 
Standardworkarounds entstehen, die aber ggf. niemals in die eigentliche 
Spezifikation einfließen. Manchmal funktionieren Geräte, die sich nicht 
streng an die formalen Spezifikationen halten, sogar wesentlich besser 
als solche, die auf strikte Spezifikationskonformität achten. Einer der 
großen Erfolgsfaktoren der Mobiltelefone von Nokia bestand darin, dass 
sie in sehr vielen Mobilfunknetzen sehr zuverlässig funktionierten. Wenn 
man solch ein Telefon aber auf dem GSM-Protokolltester untersucht hat, 
gab es aber gewaltige Überraschungen. Auch in den Protokollstacks 
etlicher anderer Telefone fand man haufenweise Workarounds für bestimmte 
Implementierungsfehler bestimmter Firmwarestände der 
Netzwerkinfrastruktur. Bei einer streng spezifikationskonformen 
Implementierung hätte das Mobiltelefon dann gar keinen Anruf (oder 
andere Funktionalität) ausführen dürfen.

> Ansonsten hätte man das SD Interface auch auf Filesystem-lvl entwickeln
> sollen... also keine Datenblöcke-Schreiben sondern eher:
>
> command <lege ein directory an>
> command <lege ein file an>
> schreibe <file>
>
> etc.... so weit klar?

Damals gab es aber komplett andere Entwurfsziele: man benötigte 
möglichst handliche Speicherkarten, die sich mit möglichst geringem 
Firmwareaufwand beschreiben lassen. Es stand niemals zur Diskussion, 
solche Speicherkarten als Haupt-Dateisysteme für "dicke" Linuxrechner 
o.ä. einzusetzen, so wie es heute ja der Fall ist. Wer "damals" einen 
Festplattenersatz suchte, war bei Compact Flash richtig aufgehoben und 
ist es teilweise auch heute noch.

> Bildhaft gesprochen Du überträgst ein Farbbild über eine schwarz-weiß
> Strecke um es dann am Ziel auf Grund von Annahmen wieder in eine
> Farbversion zu verwandeln. Geht nicht lange gut.

Was soll eine "schwarz-weiß Strecke" sein? Deine Vergleiche sind völlig 
unbrauchbar.

: Bearbeitet durch User
Autor: Mikro 77 (mikro77)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
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?

Autor: Baldrian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Baldrian (Gast)
Datum:

Bewertung
-6 lesenswert
nicht lesenswert
S. R. schrieb:

> Baldrian trollt sowieso nur rum.

Getroffene Hunde bellen. Danke für deine Rückmeldung. Du bist natürlich 
im Unrecht.

Autor: S. R. (svenska)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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?

Autor: Baldrian (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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.

Autor: S. R. (svenska)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Baldrian schrieb:
> Was hast du gegen Belege, Beweise, Quelle. Links, Studien?

Ich habe geliefert, und du moserst rum.
Liefer doch mal selbst.

Autor: Baldrian (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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.

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Piter K. schrieb:
> ich wäre damit zumindest zufrieden. Würde mich brennend interessieren,
> was für ein magischer "FAT FS follower" in der Firmware vorhanden sein
> soll.
In dem Quelltext, den du von Hyperstone bekommst,  ist natürlich nur das 
Standardgerüst. Welche Firmware gut und welche nicht so gut ist, 
entscheidet das, was der jeweilige Hersteller dazuprogrammiert. Und 
diesen Teil des Quellcodes bekommst du eben nicht.

Insofern wirst du unwissend weiterleben.

Aber mach es doch so wie ich: gehe auf ein paar größere Messen und 
löchere die Leute dort. Mit passenden Reizworten bekommst du immer 
wieder ein Häppchen Information.

Die andere Möglichkeit ist, als Firmwareprogrammierer bei einem 
Kartenhersteller anzufangen. Und dann nach und nach die ganzen 
Hersteller durchzumachen...

: Bearbeitet durch Moderator
Autor: S. R. (svenska)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Banane (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: alsGasthier (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
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 ;-((

Autor: Thomas Sch. (doschi_)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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/Standalo... 
-
Das würde zum Symptom (nur 2 Bilder) passen.

Wie hast Du die Karte neu formatiert?
Welches Betriebssystem? oder in der Kamera?

Hier würde ich empfehlen, das Programm SD Card Formatter 
"https://www.sdcard.org/downloads/formatter_4/"; zu nutzen, damit wieder 
die komplette Kapazität für die Kamera zur Verfügung steht.

: Bearbeitet durch User
Autor: Piter Kura (kurczaq)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.
       lazytime
              Only update times (atime, mtime, ctime) on the in-memory version of the file inode.

              This mount option significantly reduces writes to the inode table for workloads that perform frequent random writes to preallocated files.

              The on-disk timestamps are updated only when:

              - the inode needs to be updated for some change unrelated to file timestamps

              - the application employs fsync(2), syncfs(2), or sync(2)

              - an undeleted inode is evicted from memory

              - more than 24 hours have passed since the i-node was written to disk.

Es gibt 1001+ valide und gebräuchliche Szenarien, wo nur in das File 
geschrieben wird, aber nichts an der eigentlichen Struktur des FS 
geändert wird. Je nach FS und den mount options (oder je nach Gerät... 
wer sagt daß eine China-Cam den Timestamp selbst bei FAT aktualisiert?! 
vielleicht war man so "sparsam" und schreibt nur die EXIF Daten mit time 
stamp aber keinen timestamp in die FAT? alles schon erlebt... eventuell 
hat das Gerät überhaupt keine Ahnung von Zeit und kann so überhaupt 
keine Zeitstempel schreiben?)

Wie gesagt ich halte das für Esoterik, wenn eine Optimierung in der FW 
der Karte stattfinden soll speziell für die FAT Metadaten. Deshalb 
bleibe ich bei der Vorstellung ein BRAUCHBARES WL jenseits von Esoterik 
muss die ganze Karte berücksichtigen, unabhängig von FS. Wenn jetzt 
zusätzlich noch eine Art Heuristik implementiert ist, die speziell für 
FAT die angenommenen "wichtigen" Blöcke extra-doppelt-super-sicher 
speichert, dann tut das auch nicht weh, wenn kein FAT drauf ist.

: Bearbeitet durch User
Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Banane (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, habe das gelesen:
https://www.sdcard.org/downloads/formatter_4/SD_Ca...
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.

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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.

Autor: Frank K. (fchk)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Piter K. schrieb:
> es macht keinen Sinn
> irgendwelche FAT metadaten besonders sicher zu speichern,

Wann soll ich derartiges behauptet haben?

Autor: Piter Kura (kurczaq)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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.

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Blablabla... SD-Karten sind primär für die Datenaufzeichnung und den 
Transport von uns zu Mobilgeräten bestimmt. Zumindest war dies das 
Entwurfsziel. Deswegen wurden auch keine Dateisysteme definiert oder 
berücksichtigt, die auf die Besonderheiten von Flash-Speicher 
ausgerichtet sind. SD-Karten sind keine "ordentlichen" Speichermedien 
für den universellen Einsatz. Sie sind einfach nur billig, klein und 
einfach per SPI anzusteuern. Nur deswegen werden sie so häufig 
zwecksentfremdet.

Für mich ist diese Diskussion jetzt beendet.

: Bearbeitet durch User
Autor: Piter Kura (kurczaq)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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 ;)

Autor: S. R. (svenska)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.