Jffs - Lösungen?

Beitrag von **jmittelst** » Sonntag 6. März 2005, 15:32

Hallo,
Jffs ist ja super instabil. Hab die letzte Zeit ein wenig viel mit PlugIns gespielt und dabei x mal mein Jffs geschrottet. Gibt es da nix aktuelleres? Muß ja kein anderes Dateisystem sein, aber eine aktuellere Version oder so? Gibt es da was, oder ist das so absolut final?
cu
Jens

Beitrag von **petgun** » Sonntag 6. März 2005, 17:36

...gibt's noch was aktuelleres als die Snapshots von DietmarW? Ausser selber bauen sicher nicht. Und die Snapshots sind auch stabil...entweder liegt's imo an Dir oder an den speziellen Plugins die Du da einbaust aber nicht an den JFFS-Images.

Beitrag von **Npq** » Sonntag 6. März 2005, 17:50

Die primäre Weiterentwicklung von mtd findet schon seit längerem nur noch für die 2.6er Kernel statt. Wer das für die 2.4er haben will muß den Code entsprechend runterportieren und dazu ist offensichtlich keiner gewillt.

Beitrag von **jmittelst** » Sonntag 6. März 2005, 18:38

Ups - ich hab mich wohl missverständlich ausgedrückt. Ich meinte das Filesystem, kein Image. So wie Squashfs ja auch weiter entwickelt wird, muß es doch auch was für jffs geben, oder? Wenn es da ab dem 2.6'er Kernel weiter geht, dann ist ja gut. Suche keine Sofortlösung, sondern bin nur besorgt, da das aktuelle Jffs-Format, was ja für aktuelle Images für die /var genutzt wird doch ehr sehr instabil ist. Wer mal etwas intensiver damit arbeiten will wird es merken

cu
Jens

Beitrag von **JtG-Riker** » Sonntag 6. März 2005, 19:26

Villeicht könnte man die letzte mtd version mal versuchen einzubauen, ich befasse mich gerade damit.

Im Kernel wird ja auf eine ziemlich alte mtd version "gepatcht"

Wieso genau weis ich nicht, villeicht kann da noch jemand was zu sagen.

Gruß Riker

Beitrag von **jmittelst** » Sonntag 6. März 2005, 19:42

@JtG-Riker - Danke, das hört sich doch schon mal sehr gut an. Bin gespannt, was dabei raus kommt.
cu
Jens

Beitrag von **Houdini** » Sonntag 6. März 2005, 22:33

@JtG-Riker

ich habe bei uns auf der Arbeit einen (relativ) aktuellen mtd patch für den kernel 2.4.26 generiert. Da im Kernel in der Richtung nicht mehr viel läuft,
sollte er auch in den neuen aktuelleren funktionieren.
Ich glaube ich hatte ihn damals aus einem snapshot von der infradead seite erstellt.
Das Handling bei immer voller werdenden Flash erschien mir damit deutlich verbessert.

Vielleicht hilfts

get it under:
http://home.arcor.de/houdini/dbox/linux ... d.diff.bz2
Fehlt halt noch die dbox2 map.

Gruss
Houdini

Beitrag von **JtG-Riker** » Montag 7. März 2005, 00:44

Houdini hat geschrieben:@JtG-Riker

ich habe bei uns auf der Arbeit einen (relativ) aktuellen mtd patch für den kernel 2.4.26 generiert. Da im Kernel in der Richtung nicht mehr viel läuft,
sollte er auch in den neuen aktuelleren funktionieren.
Ich glaube ich hatte ihn damals aus einem snapshot von der infradead seite erstellt.
Das Handling bei immer voller werdenden Flash erschien mir damit deutlich verbessert.

Vielleicht hilfts

get it under:
http://home.arcor.de/houdini/dbox/linux ... d.diff.bz2
Fehlt halt noch die dbox2 map.

Gruss
Houdini

Habs mir mal angesehen, da ist aber das Problem das das jffs2 viel grösser wird, wieso auch immer, das hatte ich bei meinen Tests von heut mittag auch gehabt.

Villeicht braucht man andere parameter bei mkfs.jffs2 oder eine andere Version ?

Beitrag von **Houdini** » Montag 7. März 2005, 09:09

Was bedeutet "das jffs2 wird größer"
meinst du das image?
schau dir mal das jffs2root an, vielleicht hat sich da noch was eingeschlichen.
Der patch ist ja nur für den kernel, der sollte sich nur gering vergrößern.

Eine aktuelle mkfs.jffs2 schaded sicher nicht, aber ob es auch was bringt

Houdini

Beitrag von **JtG-Riker** » Montag 7. März 2005, 09:43

Nein, das jffs2 ist "nur" mit Logo und den "normalen" Dateien schon 400kb groß mit der neuen Version

-------

~ > df
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/root 13456 13456 0 100% /
/dev/mtdblock/3 1408 648 760 46% /var

~ > du -h
0 ./bin
512 ./etc/network
3.0k ./etc
49.0k ./tuxbox/boot
512 ./tuxbox/config/zapit
0 ./tuxbox/config/tuxmail
512 ./tuxbox/config/tuxnews
0 ./tuxbox/config/tuxtxt
9.5k ./tuxbox/config
227.0k ./tuxbox/ucodes
0 ./tuxbox/plugins
285.5k ./tuxbox
291.0k .
~ >

Das meine ich damit, 291K ist der Kram in /var und es werden 648kb verbraucht. Das hatte auch Sat-Man schon geschrieben, er hatte letztes Jahr auch mal an dem mtd Update gearbeitet.

Riker

Beitrag von **Houdini** » Montag 7. März 2005, 11:18

Ich habe da was im Hinterkopf mit der Anzahl der leeren Sektoren die das jffs2 zum Arbeiten braucht (haben will) um z.B.: ein delete bei vollem flash noch durchzuführen.

Das kann man glaube ich reduzieren. (Frag mich aber nicht wo, ich 'hab da mal was in irgendeiner mailingliste' gelesen

)

ADDED:
http://mailman.uclinux.org/pipermail/uc ... 15652.html
schreibt was von 5 sektoren,
such mal nach <mtd-jffs-HOWTO.txt> dort steht auch was darüber.
Aber warum das bei den alten jffs2 files nicht so ist weiss ich auch nicht.
Wir haben ein jffs2 only system, da fällt das nicht so auf.

Beitrag von **JtG-Riker** » Montag 7. März 2005, 12:02

Houdini hat geschrieben:Ich habe da was im Hinterkopf mit der Anzahl der leeren Sektoren die das jffs2 zum Arbeiten braucht (haben will) um z.B.: ein delete bei vollem flash noch durchzuführen.

Das kann man glaube ich reduzieren. (Frag mich aber nicht wo, ich 'hab da mal was in irgendeiner mailingliste' gelesen )

ADDED:
http://mailman.uclinux.org/pipermail/uc ... 15652.html
schreibt was von 5 sektoren,
such mal nach <mtd-jffs-HOWTO.txt> dort steht auch was darüber.
Aber warum das bei den alten jffs2 files nicht so ist weiss ich auch nicht.
Wir haben ein jffs2 only system, da fällt das nicht so auf.

Na da sollte es eben noch mehr auffallen, entweder ist da irgendwo ein Bug drin oder es ist ein Parameter anders beim mkfs.jffs2
Zumindest ist die Komperessionsrate "beschissen" mit der neuen Version, villeicht sollte man mal versuchen einen aktuellen mtd snapshot zu bauen,
allerdings is das ja alles für den 2.6er Kernel mittlerweile.

Sonst hab ich im Moment keine Erleuchtung was es sein könnte aber das /var schon ~400kb in Anspruch nimmt wenn es leer ist...

Beitrag von **Houdini** » Montag 7. März 2005, 12:41

Um die Fehlerquelle mkfs.jffs2 auszuschliessen, nimm ein altes var image und nutz es mit dem neuen kernel patch (wenn es geht).
Ist es damit auch so voll liegts am Kernel, wenn nicht ist was faul mit dem mkfs.jffs2

Beitrag von **fernsehass** » Montag 7. März 2005, 20:49

also ich hab mal gehört, das der kernel 2.4.29 auf der dbox gehen soll. jetzt ist ja 2.4.27 aktuell, aber bei 2.4.29 soll jffs bis zu 100% vollschreibbar sein.

@JtG-Riker
Du hast doch mal was gemacht, wie sind die ergebnisse ??

Beitrag von **KeXXeN** » Montag 7. März 2005, 21:05

Is nicht 2.4.29 gerade aktuell

Beitrag von **JtG-Riker** » Montag 7. März 2005, 21:06

Houdini hat geschrieben:Um die Fehlerquelle mkfs.jffs2 auszuschliessen, nimm ein altes var image und nutz es mit dem neuen kernel patch (wenn es geht).
Ist es damit auch so voll liegts am Kernel, wenn nicht ist was faul mit dem mkfs.jffs2

Hab ich schon probiert, das ist nicht der Fehler, der muss im MTD Patch sein.
hab mir den vmlinuz gesichert vor dem umbau wenn ich den nehme und sonst nix ändere ist alles okay, wenn ich den neuen nehme mit dem neuen mtd Patch dann ist das Problem vorhanden.

Gruß Riker

@Fernsehass

Der 2.4.29 läuft seit einiger Zeit in den Jtg Snapshots, allerdings gibts da schonma einen Kernel oops beim starten, wo ich noch nicht weis woher das kommt.

Beitrag von **fernsehass** » Montag 7. März 2005, 21:06

nee 2.4.27 ist im cvs

Beitrag von **Houdini** » Dienstag 8. März 2005, 08:37

also ich hab mal gehört, das der kernel 2.4.29 auf der dbox gehen soll. jetzt ist ja 2.4.27 aktuell, aber bei 2.4.29 soll jffs bis zu 100% vollschreibbar sein.

also der mtd/jffs2 teil des 2.4.29 ist immernoch derselbe wie bei 2.4.27.

Zusammengefasst:
ohne einen 'aktuellen' mtd/jfs2 patch meldet das fs mehr freien Platz in der jffs2 partition als mit.
Die Frage ist ob man diesen Platz auch nutzen kann, oder trotz des freien Bereichs nichts mehr abspeichern kann.
Das habe ich nämlich schon öfters bei meinen jffs2 only Images beobachtet: Trotz 800kb freien Platzes konnte ich nichts mehr abspeichern (und auch nichts mehr löschen). Dann hilft nur neues (bzw. altes) image drauf.

Houdini

Beitrag von **jmittelst** » Dienstag 8. März 2005, 12:40

Hmm - haben wir da jetzt etwa den Stein der Weisen berührt und das Geheimnis der gecrashten Jffs Partitionen löst sich auf? Wenn Houdinis Annahme richtig ist, setzt der neue Patch also den Speicher, den Jffs nicht nutzen kann, von Anfang an als belegt. Dann müßte der (vermeintlich) vorhandene Mehrplatz ohne Patch ja genau das Limit sein, was Jffs hat und wenn man versucht da rein zu schreiben, platzt es. Kann man das irgendwie nachvollziehen?
cu
Jens

Beitrag von **dietmarw** » Dienstag 8. März 2005, 12:55

klingt auf jeden fall sehr plausibel..

"...den Jffs nicht nutzen kann, von Anfang an als belegt"

ist mir dann wesentlich lieber als dieses "80-90% wie weit geht es noch?" rumprobieren.

Beitrag von **Metallica** » Dienstag 8. März 2005, 16:57

also , 100% geht schon mit jffs2

/dev/root 7.8M 7.7M 12.0k 100% /
/dev/root 7.8M 6.5M 1.2M 84% /

kA wie seht das auf nicht jffs2-only image.

ps.
MTD in cvs aber kaputt. Ich hab mal aus versehn damit image gebaut und nach paar lösch/schreib versuchen war image in eimer.

Beitrag von **Houdini** » Dienstag 8. März 2005, 18:16

ps.
MTD in cvs aber kaputt. Ich hab mal aus versehn damit image gebaut und nach paar lösch/schreib versuchen war image in eimer.

?? bitte nochmal anders formulieren

Was meinst Du damit?

Beitrag von **Metallica** » Dienstag 8. März 2005, 18:35

Ich habe mal mein Image mit mtd-diff aus cvs gebaut und nach paar updaten von Neutrino (file löschen neu schreiben) war Image kaputt.
Wie schon oben geschrieben , ich habe jffs2-only Image.

Beitrag von **Boxilla** » Dienstag 8. März 2005, 22:12

Sorry das ich das so sagen muss aber "blödsinn"
Das jffs Fragmentiert. Das ist einzig und allein sein problem.

Man schafft es nämlich auch durch kleine Dateien zu platzen zu bringen.
Ein ein 50%gefülltes Image kann ich problemlos eine 2 Mb grosse datei kopieren ohne es zum platzen zu bringen aber sobald mehrer kleie Dateien (1k) kopieret werden ist schneller rum.
Alles haarklein getestet. Also ich hab nach einander mehrfach ein und die selbe datei rein kopieren und wieder gelöschen, dieDateien waren unterschiedlich gross und dabei habe ich festgestellt das durch nur Kopieren und Löschen eine gewisse Fragmentation entsteht.

Man müsste es schaffen das zu Visualisieren um das begreifbar zu machen.
Fakt ist man kann es gern selber mal testen.

Was mich dann gleich zum nächsten bringt wie diese Fragmentation aufheben oder rückgänig machen. Geht natürlich garnicht da die daten von der Position auf dem Speicher wie eingefohren sind. Also statisch.

Aber was man machen kann ich dieses Image neu als Filesystem zu erzeugen.
Man bräuchte nur ein mkfs.jffs2 auf ppc und schon könnte theoretisch das image sich selbst mounten und neu erzeugen und dann natürlich neu flashen (unfragmentiert)

cu

Beitrag von **Metallica** » Dienstag 8. März 2005, 22:47

@Boxilla
Sorry aber mit "blödsinn" argumenten , kann ich nichts anfangen.
Das was ich gemacht habe war kein 2mb file.Wollte nur nicht unwichtige sachen posten.
Mach doch bei dir auf /var das gleiche was ich gemacht habe . (du darfst nur grosse file nehmen).
Das jffs2 bei 1k file ,mehr nehmt als die file grosse , ist normal.