[wiregate] Flash und so (war Communitygate ab #120)

[ZeitlerW]

Hallo Jockel,

Vorrangig geht es ja gar nicht um die Größe sondern um Optimierungen zur Schonung des Flash und ggf. zur Performancesteigerung, also z.B. der Einsatz von tmpfs wo sinnvoll oder passende Mountoptionen fürs Filesystem.

... sag ich doch siehe voyage!

vG
Wolfgang

[greentux]

(Jedes) Flash muss man sehr wohl schützen! Sonst geht in wenigen Wochen bis Monaten der Trouble los..
Das Voyage macht das schon sehr gut, da kann man gut spicken

Makki

wzbw.
Ich halte da mal dagegen:


"Since you are using CF, the wear leveling is most probably built in and so you will get no benefit using a file-system like yaffs2, jffs2 etc that have wear leveling built in. In-fact most wear leveling file-systems are not recommended for CF cards that have wear leveling built in."


Insofern... Klar, wenn man Raw NANDs nimmt, braucht man ein jffs oder ähnliches. Ansonsten würde ich mir auf 10 Jahressicht keine Sorgen machen.

[no sleep]

Ihr redet aneinander vorbei.
Das Wear-Leveling übernimmt der Controller der CF, deshalb ist ein Flash-Filesystem kontraproduktiv und man kann z.B. ext2 ohne Bauchschmerzen einsetzen.

Das hat natürlich nichts damit zu tun, sich eine entsprechende Strategie auszudenken, mit der man die Schreibzugriffe auf den Flash reduzieren/optimieren kann.

Ihr habt also beide recht.

[greentux]

Ja da gehts dann aber eher nur noch um Geschwindigkeits Vor/Nachteile. Nicht mehr um Haltbarkeit... Jedenfalls wenns CF mehr als $2 gekostet hat.

[no sleep]

Ja da gehts dann aber eher nur noch um Geschwindigkeits Vor/Nachteile. Nicht mehr um Haltbarkeit...

Nein,

das Wear-Leveling streckt grundsätzlich die Lebensdauer eines Flashs, indem es die Schreibzugriffe möglichst gleichmässig auf alle Blöcke verteilt.
Das nutzt aber nichts, wenn entweder der Flash (fast) voll ist oder die Blöcke am Ende ihrer (Schreibzyklen-)Lebensdauer angekommen sind.
Dass Industrial Flash Karten grundsätzlich im Mittel länger durchhalten als "normale" Flash Karten ist unbestritten, ändert aber an der Strategie zum Schonen des Flashs erst einmal nichts.
Deshalb sollte man die Schreibzugriffe unabhängig vom Wear-Leveling soweit reduzieren, dass man das Flash "schont", ohne zuviel Komfortverlust zu erleiden.
Nicht umsonst gibt eine CF-Karte bei einem normal installierten Windows XP schon nach ~ 1 Tag den Löffel ab.
Ausserdem bietet es sich bei den heutigen Preisen an, die Flashgrösse grosszügig zu bemessen, damit die Schreibzugriffe pro Block reduziert werden.

[greentux]

Wi elange hält denn ein "normaler" USB Stick bei einem Standard Ubuntu Install?
Nur um mal zu sehen, worüber wir hier überhaupt diskutieren...

[no sleep]

Das hängt von der Nutzung ab.
Wenn ich einen kleinen Stick in eine Kiste mit wenig RAM stecke, deshalb eine Swap-Partition auf dem Stick anlegen muss und anschliessend den gcc openoffice durchkompilieren lasse, dürfte auch nach spätestens einem Tag (hoffentlich nach Ende des Kompiliervorgangs) Schluss sein.

=> Eine pauschale Aussage dazu ist nicht möglich, da zuviele Variablen einfliessen. Mein persönlicher Erfahrungswert bei allen Flash-basierten Speichermedien ist, dass man lieber eher konservativ als offensiv mit der Flash-Nutzung umgehen sollte.

Ob man dafür in Kauf nimmt, dass bei einem evtl. Totalabsturz des Systems die letzten 10 Minuten eines Logfiles verloren gehen, muss jeder für sich selbst entscheiden.

[makki]

[QUOTE=no sleep;213564]Ihr redet aneinander vorbei.
Stimmt hier

Das Wear-Leveling übernimmt der Controller der CF, deshalb ist ein Flash-Filesystem kontraproduktiv und man kann z.B. ext2 ohne Bauchschmerzen einsetzen.

Das ist die Theorie völlig richtig, die Praxis sieht leider etwas anders aus..

Ihr habt also beide recht.

Mit dem kleinen Unterschied das ich mir hier herausnehme mal arrogant zu sein und zu sagen, das das halt so nix wird..

Wi elange hält denn ein "normaler" USB Stick bei einem Standard Ubuntu Install?
Nur um mal zu sehen, worüber wir hier überhaupt diskutieren...

Naja, Vorschlag: probiers mal 3J aus und äussere dich dann nochmal mit belegbaren Daten dazu.
Da gibts noch gefühlte 500 andere Probleme, nur um mal zu sehen, was ich übersehen habe
Mensch, ich wäre froh wenn all diese mal jemand mit einem Patch zsammschreiben würde

Wär das ein wissenschaftlich tragbarer Ansatz, bevor hier halbwahrheiten von Laien verbreitet werden?!

Makki

[no sleep]

Hi makki,

Das ist die Theorie völlig richtig, die Praxis sieht leider etwas anders aus..

Quellen? Belege? Erfahrungen?
Welches (rw!) Dateisystem würdest Du einsetzen?

[greentux]

Ich fand jetzt no sleeps Beitrag konstruktiv und ausreichend... egal.

no sleep, unter linux bleiben na vermutlich yaffs(2) und jffs(2), je nach Lizenz...

[makki]

Erfahrungen?

Nur letzteres
Aber das hast ja selbst schon geschrieben, wie lange sowas mit einer beliebigen CF gut geht (Tage, vielleicht Wochen, mehr nicht) und welche Massnahmen da helfen..

Welches (rw!) Dateisystem würdest Du einsetzen?

ext2, mit ein paar optimierungen (noatime, lazy-write,..) mit einem gescheiten Flash (SLC), das würde ich nicht nur, das mache ich..
Bisher an dieser Stelle 0,00 Ausfälle, die Vorgehensweise ist zwar teuer (eine 4GB SLC CF kostet halt 45.-, netto, EK, eine "whatever" CF 5.- EUR)

Wenn mir der Teufel nun NAND-Flash oder Sticks aus der Grabbelkiste andrehen könnte, würde ich wohl squashfs mit einem jffs2-Overlay nehmen (so wie eine bekannte Distro) aber das ist unwahrscheinlich weil ich lieber einmal in das Flash investiere und dafür keine Frickel-Dateisysteme oder Datenverluste habe

Ich fand jetzt no sleeps Beitrag konstruktiv und ausreichend... egal.

Ich auch, es ging mehr um die schlicht falsche Aussage von dir, das das ja egal wäre, man jedes CF oder nen USB-Stick vom Aldi nehmen kann, weil der sich ja "eh" drum kümmert und das alles ganz einfach ist - ist es aber nicht..
Sonst hätte ich im Büro wohl keine 15 Testsysteme stehen, die sich ständig versuchen absichtlich totzuschreiben - damit genau das beim Kunden nicht passiert..

Makki

[no sleep]

Vorab: makki, du bist manchmal *sehr* sparsam in deinen Ausführungen, das kann man(n) schnell in den falschen Hals bekommen...
Deiner Äusserungen klangen so, als wäre das, was ich geschrieben hatte, völliger Humbug.

Wenn mir der Teufel nun NAND-Flash oder Sticks aus der Grabbelkiste andrehen könnte, würde ich wohl squashfs mit einem jffs2-Overlay nehmen (so wie eine bekannte Distro) aber das ist unwahrscheinlich weil ich lieber einmal in das Flash investiere und dafür keine Frickel-Dateisysteme oder Datenverluste habe

Genau darauf wollte ich hinaus.
Sämtliche mir bekannten Flash-Dateisysteme benötigen (für mich auch nachvollziehbar) den mtd-Layer zur korrekten Block-Adressierung.
Natürlich kann man ein Squashfs-Image per Loopback von einer ext2-Partition mounten, aber damit hat man immernoch den "optimierenden" CF-Kontroller dazwischen, d.h. das über das Squashfs gelegte Jffs2 arbeitet "gegen" die wear-leveling Routinen des Controllers, mal abgesehen davon, dass das Jffs2 unter diesen Umständen das "usage-profile" des Flashs garnicht kennen kann...

Oder?!

[makki]

@Sascha: völlig einverstanden. Das ist ja genau die krux: wenn man wirklich NAND o.ä. hat, machen die Flash-Filesysteme ja durchweg Sinn; mit einer guten CF eher nicht (wobei die Hersteller ja nicht wirklich im Detail sagen, was sie machen..)
Bei einer Billig-CF oder Stick ist es eher ein Glücksspiel, vielleicht 10% besser, vielleicht aber sogar schädlich; wie sagt man so schön: your milage may vary

Makki

[greentux]

Sascha, d.h. das mein SSD mit Standard Ubuntu im Notebook am Rande des Wahnsinns ist ?
Kernel/Xorg kompilieren kommt schon mehrmals im Monat vor...

Gibts im Linux eine Art Feedback von der disk (bei SATA sagte SMART ja immer mal Bescheid...)?

[makki]

Ich habe den Thread mal abgetrennt, da es denke ich nicht viel mit dem Ursprungsthema zu tun hat..

Sascha, d.h. das mein SSD mit Standard Ubuntu im Notebook am Rande des Wahnsinns ist ?

Naja, ich weiss es nicht aber das ist der Grund warum ich - trotz all der Vorteile noch keine SSD drin habe: Das was da verkauft wird ist eher *** - mit MLC-NAND-Flash, der halt nunmal so roundabout irgendwann putt gehen muss.
Wear-Leveling hin oder her, ich denke darauf basieren aktuell die meisten SSD's, das sie davon ausgehen das eben wenig ständig geschrieben wird - dann klappt das auch..
Aber wenn dem nicht so ist, weil man die SSD auch "aktiv" benutzt, hmm, ich wills nicht mit Produktiv-Daten ausprobieren..

Wikipedia:

MLC-Chips haben mit 10.000 Zyklen je Zelle ein Zehntel der Wiederbeschreibbarkeit der SLC-Technik.

Diese 10.000 sind irgenwann rum, egal wie perfekt der Controller das mit dem Wear-Leveling macht..
Es wird nun drauf ankommen wie man das Ding rannimmt, ich bin da skeptisch - für einen "normalen User" wird das sicher lange gut gehen, wenn man sich die SSD aber reinpackt, gerade weil man 2x in der Woche mal einen make clean; make -j 8 übers openwrt laufen lässt - fraglich? Also es ist sicher erstmal schneller aber wielange=??
Es wird sterben, irgendwann; ok das tut die alte Platte auch aber im Schnitt nicht nach 10k Schreibzyklen pro Sektor/Block.
Daher stehe ich zwar auf Flash, aber im Livebetrieb bitte Männerware (SLC), kein Spielsachen (MLC); da kostet das Gig halt mal 15.- EUR, ist eben so

Gibts im Linux eine Art Feedback von der disk (bei SATA sagte SMART ja immer mal Bescheid...)?

Also die (ernsthaften SSDs / CF) die ich kenne können alle SMART. smartmontools (oder so) installieren..
Und sichern, aber das gilt Medien-Unabhängig..

Makki