Haltbarkeit des GP2x bzw. "Wann gibt mein NAND auf&quot


Miyu said:
Jede Technik geht irgendwann mal kaputt. Hier geht es ja nur darum, den Zeitpunkt möglichst lange hinauszuzögern :)
das stimmt nicht :)...
aus meinem alten NES kam schon etliche male rauch raus... nach 10 mins warten geht er immer wieder :D ... und er hat sicher schon 2-5jahr betriebszeit... (der läuft/lief bei mir dank fehlender speicher funktion bei manchen spielen fast immer )
 
Aber wenn ich ein absolut neues Gadget wie den Gp2X besitze und er mir nach wenigen Wochen (Monaten, Jahren) abschmiert, dann kanns das doch auch nicht sein, oder. Der Gameboy (schwarz-weiß) meines Vaters läuft jetzt auch schon seit mehr als 10 Jahren tadellos.
 
solche haltbarkeitswerte sind immer sehr relativ zu sehen.
wenn es wirklich eine millionen zugriffe pro baustein sind, liegt das möglicherweise ja schon ausserhalb der lebenserwartung des gerätes.

aber auch das sind ja nur erwartungswerte. nach solchen werten sollten auch meine über 20 jahre alten C64er isketten nicht mehr lesbar sein. sind sie aber noch.

trotzdem ist es natürlich gut, die zahl der zugriffe auf ein minimum zu reduzieren. denn hier kann man die lebensdauer beeinflussen, was bei disketten und modulen weitgehend nicht der fall ist.
 
Das heißt, ich sollte das oben aufgeführte Skript installieren ???
 
Nein, das ganze ist noch suboptimal und bringt recht wenig. Ich werde sehen, das ich noch eine Version zusammengebacken bekomme die ohne Schreibzugriffe auskommt.
 
Re: Haltbarkeit des GP2x bzw. "Wann gibt mein NAND auf&

<r><QUOTE author="kilroy"><s>
kilroy said:
</s>
D.h. ein Bootvorgang schreibt mindestens mal 50 mal auf das NAND... d.h. nach 2000mal Booten oder 1000mal Booten und ein paar Programme starten fängt das NAND an, kaputt zu gehen...
<e>
</e></QUOTE>
Soweit ich weiss gibt es dafuer in der Controllerlogic auf unterster Ebene ein Defektmanagement der ueber genuegend Reservebereiche verfuegt um solche Defekte durch remapping zu ersetzen. Die 50 Schreibvorgaenge betraefen ja auch nur einen winzigsten Bruchteil der Kapazitaet im Verhaeltnis zur Gesamtkapazitaet des Speichers und duerfte sich locker im Fehlerfalle regelmaessig damit ersetzen lassen.<br/>
Problematisch wuerde es warscheinlich nur werden wenn die maximale Schreibzyklenzahl ueber einen nennenswerten Speicherbereich erreicht werden wuerde also bspw. 10 Prozent oder mehr des gesamten Speichers komplett neu beschrieben werden wuerde. Bei so etwas die maximale Zyklenzahl zu erreichen duerfte aber kaum moeglich sein ausser man wuerde so komische Sachen wie Swapping oder aehnliches auf so einem Speicher anstellen.</r>
 
Ein neues "optimales" Skript wäre cool ! In jedem Falle sollte der Hersteller mal befragt werden, was er dazu sagt (Garantie usw.).
 
So, das ganze ist jetzt mehr oder minder ausgegoren, nachdem ich ein halbes Duzend mal das Filesystem neu flashen musste (oder unabsichtlich geflasht habe, weil ich das ding von der karte nicht gelöscht habe :( )

Und ich muss zugeben, ich hatte einen Denkfehler. devfs ist natürlich kein Problem hierbei, schließlich ist devfs ein virtuelles Dateisystem - alles was dort gemacht wird kann uns eigentlich sch***egal sein.

Ich habe jetzt die scripte soweit abgearbeitet, dass nur noch utmp beschrieben wird. Ich hatte gerade eine Idee, wie man das löst, leider hatte ich auch noch ein gp2xfile.img auf der SD als ich das testen wollte :x

Das einzige Problem was bleibt ist die SD Karte. Zwar mountet er die mir jetzt in der profile brav mit noatime, nur gibt es da ja immer noch die entsprechenden automounter im kernel und in gp2xmenu :(
 
Wo machst du denn jetzt das remount read only?

Wohl nicht im U-Boot, oder?
 
Bis jetzt remountet er den NAND im Initscript als noatime,rw und in der profile als ro.
Wenn ich es hinkriege, dass die utmp nicht benötigt wird kann man direkt im initscript das ganze auf ro stellen.
 
Was spricht denn gegen das Automounten der SD-Karte? Oo

Gegen das Automounten an sich? Nichts :)

Gegen das Automounten, wie GPH es macht, einiges:

- SD Karten werden zwangsweise als vfat gemountet, sprich es funktioniert nicht mit ext2 fomatierten Karten

- SD Karten mit vfat werden ohne noatime gemountet, was nicht sonderlich schonend für die karten ist.

Aber egal, ich habe das jetzt mehr oder weniger krude umschifft und schnüre gerade das Paket :)
 
Da war das "Betriebssystem" ja nicht mehr als ein Launcher und der Speicher war nicht viel größer. Daher wurde nur auf die SM-Karte geschrieben.
 
hmm also so recht will ich mir keinen Reim draus machen - imo ist flash speicher mit das narrensicherste der letzten jahre.

wie in meinem "Vorstellungs-thread" erwähnt hatte ich vor kurzem nen Leergang im Bereich Halbleitertechnologie belegt - da hatte ich mal das Tema Flashspeicher angeschnitten und von unserem Dozenten im Labor nen recht ordentlichen Kurzvortrag drüber bekommen

leider bekomme ich den aus m stehgreif auch nicht mehr zusammen ;) - und hab auch keine Seiten am start die das untermauern - laut herstellerangaben können flash-eproms (und das dürften afaik diese NAND-Bausteine sein) 50 bis 99 Jahre die Informationen halten, die auf ihnen gespeichert sind und da kann ich mir nich vorstellen, dass da nach nur 1000 Lese und oder schreibzugriffen sense sein soll - klingt für mich nich ganz schlüssig

desweiteren werden diese Speicher heutzutage in quasie allen technischen Geräten verwendet - und teoretisch hätte da mein über ein jahr alter usb-stick auch schon seinen geist aufgeben müssen

glaubt mir wenn ich sage dass ich einem silizium-baustein durchaus was zutraue :D - und denke mal dass GamePark (auch wenn ich die bisher nich kannte) da keinen Schund zusammengabut hat, der gleich nach ner Weile zusammenfällt
 
dass da nach nur 1000 Lese und oder schreibzugriffen sense sein soll

1000 mal booten -> 1000 x 50 (schreibzugriffe/boot) = 50000 schreibzugriffe

darum gehts ;)

und darum das es zurzeit so eingestellt ist das jeder lesezugriff gleichzeitig ein schreibzugriff ist (so hab ich das zumindestens verstanden)
laut herstellerangaben können flash-eproms (und das dürften afaik diese NAND-Bausteine sein) 50 bis 99 Jahre die Informationen halten

Das bezieht sich aber wohl auf Daten die sich nicht ändern. Hat also nicht mit Schreibzugriffen zu tun.
 
Nur mal eine grundsätzliche Verständnisfrage (auch wenn ich die Antwort schon vermute): den Speicher ersetzen wäre für Normalsterbliche vollkommen undenkbar, oder? Wäre es ansonsten machbar, GPH zu überzeugen, den Speicher in der nächsten Revision zu sockeln, damit man ihn bei Bedarf tauschen (lassen) kann? ED ...?
 
Ben said:
dass da nach nur 1000 Lese und oder schreibzugriffen sense sein soll

1000 mal booten -> 1000 x 50 (schreibzugriffe/boot) = 50000 schreibzugriffe

darum gehts ;)

und darum das es zurzeit so eingestellt ist das jeder lesezugriff gleichzeitig ein schreibzugriff ist (so hab ich das zumindestens verstanden)
öhhm - also so wie ich das denke verstanden zu haben ;) - gehts darum dass einige bammel haben der NAND-speicher könnte danach quasie kaputt gehen und währe nicht mehr zu gebrauchen
laut herstellerangaben können flash-eproms (und das dürften afaik diese NAND-Bausteine sein) 50 bis 99 Jahre die Informationen halten

Das bezieht sich aber wohl auf Daten die sich nicht ändern. Hat also nicht mit Schreibzugriffen zu tun.
stümmt soweit - aber !! - wenn ein hersteller solche angaben macht dann geht man ja wohl davon aus dass in dieser zeit ne menge von dem speicher gelesen bzw. drauf geschrieben wird - oder ?? - darauf wollte ich hinaus :D

ähnliches beispiel - hat schon jemand die Lebensdauer von Arbeitspeicher oder einer CPU überschritten ??? ;) - meine ohne Übertakten oder andere böse Sachen - sowas macht man schließlich nicht ;) .... - oft sind die komponenten eher ihrer Leistungsfähigkeit überholt - und wie es schon so passend die meisten erwähnt haben, kann ich mich nur anschließen - mein Classic Game Boy funzt auch noch einwandfrei

also keine bange - eh das ding kaputt geht is schon der GPX45-f250 drausen ;)
 
OK, habe alles fertig und knapp 100 mal getestet, es läuft alles einwandfrei.

Das Update ist hier zu finden:

http://archive.gp2x.de/cgi-bin/cfiles.cgi?0,0,0,0,42,1081

README lesen ist Pflicht, auch wenn es mehr oder weniger automatisch läuft :)

Features:

1. Beim Booten werden KEINE Dateien mehr auf dem NAND erzeugt. Die Bootscripte sind jetzt sauber und gut kommentiert.

2. Der NAND wird als read-only gemounted, damit kein schlecht programmiertes Programm im Filesystem Amok laufen kann.

3. Der /root Ordner ist auf die SD Karte gelinkt, da dort auch der meiste Kram landet, auch die .bash_history die beispielsweise die Shell in sterm erzeugt.

4. SD Karten werden mit noatime gemountet, was deren Haltbarkeit dienlich ist.

5. ext2 formatierte Karten werden unterstützt

6. ext2 formatierte Karten unterstützen auto-sync und sind deshalb weniger anfällig für batterieversagen
 
ma noch ne frage zum mounten (weil bin noch nich der linux-experte, der ich gerne währe ;) ) - auch wenns n bissel OT wird. Ich hab da mal n büschen gegoogelt - soweit ich das gerafft hab betrifft dieses mounten nur das Laufwerk - sprich den SD-Slot - oder wird da mit der Karte selber auch noch was "gemacht" ???? müsste man da jede SD Karte extra mounten oder reicht es sie quasie nur zu formatieren (afaik FAT32)
 
Back
Top