No Name micro-SD(XC) - Schnäppchen oder Risiko?

  • readonly ist mein Stichwort, hast du schon versucht, den readonly-Attribut zurückzusetzten? Manchmal passiert das aus unerfindlichen Gründen, dass es ohne dass du es möchtest, gesetzt wird. "Lustig" ist, dass es dazu seltenst eine Fehlermeldung gibt.

  • readonly ist mein Stichwort, hast du schon versucht, den readonly-Attribut zurückzusetzten?

    Aber beim vollständigen Formatieren oder Flashen eines Images wird der alte Inhalt der SD-Karte blockweise überschrieben, unabhängig von den auf der SD vorhandenen Daten bzw. irgendwelchen Attributen eines Dateisystems.


    Was aber in meinen Augen sein kann, dass die µSD für den RPi zum Bearbeiten am PC in einem SD-Adapter steckt und dessen LOCK-Schieber nicht (mehr) richtig funktioniert. Ich hatte schon SD-Adapter, bei denen dieser Schieber so leichtgängig wurde, dass er beim Einschieben in den (großen) SD-Schacht am PC verschoben wurde. Dann kann natürlich passieren, dass das Schreiben hardwaremäßig nicht durchgeführt wird. Die Fehlermeldung am PC hängt dann von irgendwelchen Treibergeschichten ab...


    Aus eigener Erfahrung:

    Kritisch ist auch, den SD-Adapter im Cardreader zu belassen und einfach nur die µSD zu entfernen. Da kann es sein, dass das Carddetect-Signal weiterhin anliegt, da dies durch einen mechanischen Schalter im SD-Adapter des Readers geschaltet wird, der ja durch den SD-Adapter betätigt ist. Dass die µSD fehlt, kann der Cardreader (und ein OS-Treiber) jedenfalls über dieses Signal nicht feststellen.


    Dies ist auch der Fall, wenn ein USB-Cardreader am RPi angeschlossen wird und damit der Zugriff auf die µSD-Karte erfolgt.

  • würde ich wahrscheinlich noch mal bei ausgezogener Karte neu booten und sie mir dann noch mal anschauen

    gesagt getan, in der .config liegen noch meine Bilder Icons können angesehen werden

    /media/pi/7f593562-9f68-4bb9-a7c9-2b70ad620873/home/pi/.config

    und ein Bild konnte ich löschen


    wie das nach dd über alles sdb?

    wie das nach Partitionen löschen?

    achso Karte raus wieder rein, Bild wieder da!


    Karte wirklich kaputt? ich denke immer noch ja

    in einem SD-Adapter steckt und dessen LOCK-Schieber nicht (mehr) richtig funktioniert.

    kenne ich auch nur warum sagt der PI er hat alles richtig gemacht, dd, Löschen? nur win32diskimeger sagt er konnte nicht schreiben

    das mit dem Schreibschutzschalter prüfe ich mal.


    Schreibschutzschalter fixiert

    win windows eine Kopie der /boot/config.txt eingefügt, wird auch durchgeführt, Karte raus(mit auswerfen) rein, Kopie ist nicht mehr anwesend


    PS. ich sehe gerade die meisten Dateien im boot root sind vom 5.5.2018 als ich versuchte mit dem win32diskimager das raspbian neu zu schreiben und es mit Fehler abbrach.

    lasst die PIs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr

    2 Mal editiert, zuletzt von jar ()

  • Hallo jar,


    um den Bogen in Richtung Topic zu spannen: Ich habe vor ein paar Tagen hier irgendwo im Forum gelesen, da hatte jemand für extrem wenig Geld eine riesige SD-Karte gekauft... ;)

    "Alles, was wir sind, ist Sand im Wind, Hoschi."

  • um den Bogen in Richtung Topic zu spannen:

    ich hoffe mal Karte kaputt (schreiben) war nicht so weit weg vom Topic, Dirk hatte ja nicht wirklich um Hilfe gerufen.

    im Forum gelesen, da hatte jemand für extrem wenig Geld eine riesige SD-Karte gekauf

    und das gönne ich ihm, auch wenn ich meine Lebenszeit nicht an einer microSDXC vergeuden würde, schon meine 10TB Platte am USB3 nervte mit 12 Stunden.


    Ich selle mir gerade bildlich vor Imagesicherung einer 256GB Platte, nun gut auf 10TB passt sie immerhin 40x rauf :lol:

    lasst die PIs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr

  • sry for late ..


    Denke nun, die Karte ist Schrott..


    Ich tippe auf einen Kontrollerfehler der SD-Karte: Lesen ja, aber der Schreibbefehl wird nicht (mehr) umgesetzt.


    Zum Schreiben wird ja mit (leicht) erhöhter Spannung (10-18V) an die Zellen gegangen, vermutlich ist der Spannungskonverter ausgefallen, so dass die Zellen weder gelöscht noch neu beschrieben werden können...


    Mit dem Schreibschutzschalter hat das alles nix zu tun: Das ist ein rein mechanischer Schalter, welcher der SD-Card-Kontroller abfragt (oder er ignoriert ihn, ist reine SW)...

    ...schon meine 10TB Platte am USB3 nervte mit 12 Stunden.


    Ich selle mir gerade bildlich vor Imagesicherung einer 256GB Platte, nun gut auf 10TB passt sie immerhin 40x rauf :lol:

    Mein NAS sichert z.Zt. ca. 4TB auf die Backup-Platte (auch 4TB) komprimiert in ca. 14-18h...


    Wobei: Die Platte ist im NAS Erweiterungsrack eingebaut und wird nur für den Backupfall eingeschoben...


    Läuft über Nacht, da kümmert mich das eher wenig..

  • Ich tippe auf einen Kontrollerfehler der SD-Karte: Lesen ja, aber der Schreibbefehl wird nicht (mehr) umgesetzt.

    So einen Fehler haben jetzt schon zwei mal Benutzer von raspiBackup berichtet: Das restorte Backup (auf eine fehlerhafte SD Karte) funktionierte eigentlich normal. Wenn man Dateien geändert hat wurden sie geändert und alles war OK. Wenn man dann rebootet hat waren die Änderungen wieder weg :denker:. Es lag daran dass die geänderten Verzeichniseinträge nicht mehr auf die SD Karte geschrieben werden konnten. Solange man die gecachten Einträge benutzte lief alles OK. Nach einem Reboot waren aber wieder die alten Verzeichniseintraege da. Hat beim ersten Mal etwas länger gedauert bis wir die Ursache gefunden hatten :wallbash:

  • Mein NAS sichert z.Zt. ca. 4TB auf die Backup-Platte (auch 4TB) komprimiert in ca. 14-18h...


    Wobei: Die Platte ist im NAS Erweiterungsrack eingebaut und wird nur für den Backupfall eingeschoben...

    ich hatte ja fürs NAS mit 3x 3TB schon eine 8TB Platte fürs backup gekauft, ins USB3 Gehäuse gesetzt und nur gelegentlich eingeschaltet für backup.

    Als das NAS eng wurde habe ich eben diese 8TB in dne freien Einschub gesteckt und das nun leere Gehäuse mit der 10TB bestückt und diese wissentlich am win7 mit NTFS formatiert. Immer in den NAS Schacht schieben oder den Schacht offen lassen oder die Platte in den Cover zu schrauben war mir zu umständlich.

    lasst die PIs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr

  • ...10TB bestückt und diese wissentlich am win7 mit NTFS formatiert.

    Erkenne den Fehler (!!) :-)


    Das NAS läuft mit Unix, der NTFS Treiber ist in Linux-Systemen die Filesystem-Bremse schlechthin (wenn es auch schon besser geworden ist...)


    Formatier die Backup-Platte mit einem Linux-Filesystem und die Kopierrate wird sich wesentlich erhöhen.


    BTW:

    Das Einbauen / Einsetzen und entnehmen des Plattenrahmens in das NAS-Gehäuse dauert geschätzte 3sec., mit Entnahme aus dem Schutzcontainer (Wasser/Staubschutz) nochmal zusätzlich ca. 5-10sec.


    Wenn kein Plattenrahmen im Rack ist, mach ich da immer 'n Tape drüber, oder 'ne Gardine :lol:

  • Erkenne den Fehler (!!) :-)

    ist kein Fehler, am USB ist die Platte öfter am win als am Linux


    Das NAS läuft mit Unix, der NTFS Treiber ist in Linux-Systemen die Filesystem-Bremse schlechthin (wenn es auch schon besser geworden ist...)

    das war kein Problem auch gehts lieber über den Win Rechner weil ich da mehr Kontrolle habe, die Qnap Copy Routinen im Webbrowser nerven


    Das Einbauen / Einsetzen und entnehmen des Plattenrahmens in das NAS-Gehäuse dauert geschätzte 3sec., mit Entnahme aus dem Schutzcontainer (Wasser/Staubschutz) nochmal zusätzlich ca. 5-10sec.

    Qnap will geschraubt werden.

    lasst die PIs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr

  • Hi Zentris ,

    k.A. ... ich hab das einfach mal angeschmissen und das füllt scheinbar die SD mit Pattern-Dateien zu je gut 1 GB.

    Momentan ist es bei Nummer 100 ...

    Pro Datei scheint er so ca. 1/2 Stunde zu brauchen.

    Bis jetzt hat der f3write ca. 24 Minuten CPU Zeit verbraucht (also ca. 15 Sekunden CPU pro Datei) ... scheint also einiges an Overhead drin zu sein.


    cu,

    -ds-

  • Naja ... ich denke die Schreibgeschwindigkeit kann man da ja mal separat testen.

    So rein vom Gefühl war die nicht merklich langsamer als die Karten, die ich sonst verwende. Ich hatte ja einiges hin und her kopiert und auch Images mit dd geflasht. Allerdings hatte ich da nicht speziell auf die Schreibgeschwindigkt geachtet ...


    So in 1 bis 2 Tagen sollte der f3write durch sein, dann schmeiss ich noch den f3read an und dann steht erstmal das erste Ergebnis.


    cu,

    -ds-

  • So ... f3write ist durch ...


    jetzt mal den f3read anschmeissen und gucken was passiert ...


    cu,

    -ds-

  • Soo ...

    ich habe den f3read jetzt mal abgebrochen.

    Mich hat das Ergebnis jetzt schon sehr gewundert:


    Das ist schon ziemlich sonderbar ...

    Denn:


    Alle Dateien haben die selbe CRC32 Checksumme ... sind also alle gleich "falsch" bzw. "corrupted" :conf:


    Ich denke, hier kommt der f3write und/oder der f3read mit dem exFAT filesystem nicht klar, denn dass die kopierten VM-Dateien anstandslos zurückgesichert werden konnten und problemlos funktionieren, deutet für mich drauf hin, dass das Schreiben und Lesen über den "exFAT" Treiber scheinbar problemlos möglich ist.


    Naja ... jedenfalls immer noch keine Fehlermeldungen - also tut das Teil.

    Ich denke, ich schliesse das hier ab und warte, bis ich mal SD-Karten mit manufacturer id bekomme.


    Muss jeder für sich entscheiden, ob er NoName vertraut oder nicht. Wie jar einsrucksvoll beschrieben hat, sind ja auch Marken-Karten gegen plötzlichen Totalausfall auch nicht gefeit.


    cheers,

    -ds-

  • Hallo zusammen,

    ich hatte ja noch 512 GB Karten geordert. Die sind heute eingetroffen.

    Allerdings haben die auch keine Hersteller-Kennung (steht auf 0x00). Deshalb macht da ein weiterer Test keinen Sinn.

    Ich habe allerdings mal einen Performance Test der Karten durchlaufen lassen ( ist Bestandteil meiner Ubuntu-Distri).


    Die Ergebnisse:


    das ist der vorher schon gequälte Verbatim-Clone mit 256 GB.



    und das die beiden 512 GB Karten.


    Auffällig ist der schwache Datendurchsatz.

    Das kann allerdings wieder am exFAT Dateisystem liegen, das unter Linux nicht besonders gut unterstützt wird.


    So, und damit schliesse ich das Thema jetzt aber endgültig ab.


    ciao,

    -ds-

  • Wie jar einsrucksvoll beschrieben hat, sind ja auch Marken-Karten gegen plötzlichen Totalausfall auch nicht gefeit.

    nun ja ob es Merkenkarten oder Fälschungen waren weiss ich ja nicht, so ein Aufdruck wird natürlich auch gefälscht, das bewiesen schon unzählige SanDisk Karten von allen möglichen Händlern. Sicher könnte man nur sein wenn die Vendor ID nicht gefälscht werden kann und sich als Original ausweist, aber auch das wird wohl oft vernachlässigt. Dabei steht SD für "SD-Karte (von englisch Secure Digital Memory Card „sichere digitale Speicherkarte“)" eigentlich ein Witz unter diesen Umständen.

    lasst die PIs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr