neues Dateisystem UBIFS für Flashspeicher

Sklaventreiber
deathrattle
Beiträge: 1
Registriert: Sonntag 30. November 2008, 14:10

neues Dateisystem UBIFS für Flashspeicher

Beitrag von deathrattle »

Nokia hat ja ein neues Dateisystem für den Flashspeicher kreiert.

Wenn ich mir den Vergleich zum JFFS2 ansehe, so sollte dies doch sehr interessant sein.

Ist in diese Richtung etwas geplant, bzw. wird schon etwas getestet?

http://osl.sed.hu/wiki/ubifs/index.php/Main_Page
http://www.linux-mtd.infradead.org/doc/ubifs.html
http://www.inf.u-szeged.hu/sed/ubifs
rhabarber1848
CDK-Experte
Beiträge: 4335
Registriert: Donnerstag 3. April 2008, 14:05

Re: neues Dateisystem UBIFS für Flashspeicher

Beitrag von rhabarber1848 »

http://svn.dd-wrt.com:8000/dd-wrt/ticket/688
but has one major disadvantage. the compression is not as good as jffs2. no 2.4 kernel support (required for broadcom tree) and do consider too that our jffs2 is based on lzma and not zlib which additionally increases compression ratio and yet jffs2 is a journaling filesystem too. the speed advantage at mount time doesnt matter for 4 - 8 mb flash devices. ubifs was designed for flash devices much bigger additionally ubifs doesnt work on top of mtd devices. you must add a new ubi layer inbetween. this is another disadvantage since this will make a 2.4 kernel backport difficult. we dont need overhead for small volume devices
Kernel 2.4-Support wird für Tuxbox allerdings benötigt, da hiermit die meisten Images laufen.
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Re: neues Dateisystem UBIFS für Flashspeicher

Beitrag von seife »

Ich habe mich auf der ELC-E in Ede sowohl mit Michael Opdenacker (http://www.embeddedlinuxconference.com/ ... Opdenacker), der dort einen interessanten Vortrag über die verschiedenen Flash-Filesysteme gehalten hat, als auch mit Philip Lougher (SquashFS) und David Woodhouse (jffs2) darüber unterhalten und alle waren der Meinung dass für ein dermassen eingeschränktes Gerät wie die dbox2 die Kombination aus SquashFS und jffs2 oder auch nur jffs2 so ziemlich das beste ist, was man verwenden kann.

Bei modernen Embedded-Geräten wird man andere Dateisysteme wählen, aber dann halt auch einfach doppelt soviel FLASH und RAM einplanen.
doc
Contributor
Beiträge: 1623
Registriert: Donnerstag 10. Januar 2002, 20:03

Re: neues Dateisystem UBIFS für Flashspeicher

Beitrag von doc »

UBIFS ist eher für die aktuellen USB-Sticks bzw. deren Flashgrößen interessant. Die 8MB der dbox2 sind da eher Kinderkram :wink:
Aktuelle Flash können sich in gewisser Weise selber intelligent verwalten beim schreiben. Der Controller wählt per Zufallsprinzip jedes mal neu aus wohin die Daten geschrieben werden.
AudioSlyer
Erleuchteter
Erleuchteter
Beiträge: 450
Registriert: Sonntag 28. Juli 2002, 01:18

Re: neues Dateisystem UBIFS für Flashspeicher

Beitrag von AudioSlyer »

seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Re: neues Dateisystem UBIFS für Flashspeicher

Beitrag von seife »

Ich schreibe hier lieber nicht, was die Filesystem-Leute zu den LZMA-Patches gesagt haben ;)
rhabarber1848
CDK-Experte
Beiträge: 4335
Registriert: Donnerstag 3. April 2008, 14:05

Re: neues Dateisystem UBIFS für Flashspeicher

Beitrag von rhabarber1848 »

seife hat geschrieben:Ich schreibe hier lieber nicht, was die Filesystem-Leute zu den LZMA-Patches gesagt haben ;)
Ooch, bitte, lass uns nicht dumm sterben ;)
Eigentlich wollte ich fragen, ob es für Kernel 2.4 auch einen jffs-lzma Patch gibt.
doc
Contributor
Beiträge: 1623
Registriert: Donnerstag 10. Januar 2002, 20:03

Re: neues Dateisystem UBIFS für Flashspeicher

Beitrag von doc »

dann schaue man sich mal den Code vom LZMA an dann kann man sich denken was andere dazu sagen würden ... 8)
Umsonst ist der noch nicht im Kernel enthalten.
AudioSlyer
Erleuchteter
Erleuchteter
Beiträge: 450
Registriert: Sonntag 28. Juli 2002, 01:18

Re: neues Dateisystem UBIFS für Flashspeicher

Beitrag von AudioSlyer »

Dann verschönert ihn mal, passt doch zum Neutrino :D
Bei mir rennt das JFFS2-LZMA seit 4 Monaten ohne Probleme.
rhabarber1848
CDK-Experte
Beiträge: 4335
Registriert: Donnerstag 3. April 2008, 14:05

Re: neues Dateisystem UBIFS für Flashspeicher

Beitrag von rhabarber1848 »

AudioSlyer hat geschrieben:Bei mir rennt das JFFS2-LZMA seit 4 Monaten ohne Probleme.
Wieviel Prozent bringt die LZMA-Kompression in Deinem Fall?
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Re: neues Dateisystem UBIFS für Flashspeicher

Beitrag von seife »

Es wird auf jeden Fall viel langsamer, wie auch beim squashfs. Das ist AudioSlyer egal, da er schnellere Prozessoren nutzt, aber auf der dbox ist das schlecht.
AudioSlyer
Erleuchteter
Erleuchteter
Beiträge: 450
Registriert: Sonntag 28. Juli 2002, 01:18

Re: neues Dateisystem UBIFS für Flashspeicher

Beitrag von AudioSlyer »

Man schreibt ja nicht ständig was in den Flash, daher ist die Geschwindigkeit nicht ausschlaggebend.
mrvica
Einsteiger
Einsteiger
Beiträge: 342
Registriert: Freitag 24. September 2004, 12:48

Re: neues Dateisystem UBIFS für Flashspeicher

Beitrag von mrvica »

vielleicht könnte man den LZMA Code etwas verbessern und effezienter machen, die letze UPX Version hat auch LZMA Patch drin, die Sourcen in C++ sind frei verfügbar, der Code sieht für mich anders aus (bin da kein Experte), UPX ist sehr schnell auf der dbox2, ~3MB enigma binary gepackt ~1MB, startet gleich oder tick schneller als ungepackt, gleich eine Frage dazu, upx ist nicht kompatibel mit dietmarw Images, es liegt wahrscheinlich an allzu gestrippten libc.so.6, vlc Plugin für Enigma will auch nicht, könnte man das fixen
http://upx.sourceforge.net/

mrvica
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Re: neues Dateisystem UBIFS für Flashspeicher

Beitrag von seife »

AudioSlyer hat geschrieben:Man schreibt ja nicht ständig was in den Flash, daher ist die Geschwindigkeit nicht ausschlaggebend.
Seit ich kein LZMA mehr für's squashfs benutze, bootet meine Box fast doppelt so schnell. Es macht also auch beim Lesen einiges aus. Vergiss nicht: die dbox ist wesentlich langsamer als deine boxen.
doc
Contributor
Beiträge: 1623
Registriert: Donnerstag 10. Januar 2002, 20:03

Re: neues Dateisystem UBIFS für Flashspeicher

Beitrag von doc »

Naja, es soll ja auch Leute geben die finden die ca. 120 sec. Bootzeit der Dreams vollkommen in Ordnung. :wink:

Was bei den Satboxen einen nicht unerheblichen Anteil der Bootzeit ausmacht ist das Parsen der Bouquets und Services. Und die liegen ja im /var, haben also nix mit squashfs und lzma zu tun.

Naja, man viel darüber diskutieren. Ohne Vergleichswerte kann man nur spekulieren. Aber um es testen zu können müsste es jemand lauffähig machen. :wink:
rhabarber1848
CDK-Experte
Beiträge: 4335
Registriert: Donnerstag 3. April 2008, 14:05

Re: neues Dateisystem UBIFS für Flashspeicher

Beitrag von rhabarber1848 »

doc hat geschrieben:Aber um es testen zu können müsste es jemand lauffähig machen. :wink:
Dann mache ich mal den Anfang, hier ein Patch für optionalen
LZMA-Support in mkfs.jffs2: EDIT: Patch ist im CVS

Code: Alles auswählen

$(MKJFFS2) -x lzma
bedeutet, dass bei den existierenden make targets auf LZMA-Komprimierung
verzichtet wird. Weiter bin ich noch nicht, ich habe aber ungetestete JFFS2/
LZMA-Patches für Kernel 2.6 und 2.4 gefunden, die ich noch einbinden werde.
Hier geht es nun darum, dass dieser Patch für normale JFFS2-Partitionen
nichts kaputt macht.
Zuletzt geändert von rhabarber1848 am Sonntag 2. August 2009, 17:45, insgesamt 1-mal geändert.
rhabarber1848
CDK-Experte
Beiträge: 4335
Registriert: Donnerstag 3. April 2008, 14:05

Re: neues Dateisystem UBIFS für Flashspeicher

Beitrag von rhabarber1848 »

Hast Du schon ein JFFS2/LZMA-Image mit U-Boot gestartet?
rhabarber1848
CDK-Experte
Beiträge: 4335
Registriert: Donnerstag 3. April 2008, 14:05

Re: neues Dateisystem UBIFS für Flashspeicher

Beitrag von rhabarber1848 »

Mit diesen Patches und "make flash-$gui-squashfs-all" kann ein Image
kompiliert werden, dessen JFFS2-Partition lzma-komprimiert ist.

LZMA-Support für JFFS2-Kernelmodul: EDIT: Patch ist im CVS
LZMA-Support für mkfs.jffs2 (siehe oben): EDIT: Patch ist im CVS

Erstellen von /var als JFFS2/LZMA-Partition: EDIT: Patch aus dem ULC entfernt
Hier der Patch:

Code: Alles auswählen

--- cdk/make/partition-images.mk	2009-07-06 12:55:06.000000000 +0200
+++ cdk/make/partition-images.mk	2009-07-06 12:56:05.000000000 +0200
@@ -6,7 +6,7 @@
 $(flashprefix)/var-enigma+neutrino.jffs2 \
 $(flashprefix)/var-enigma.jffs2: \
 $(flashprefix)/var-%.jffs2: $(flashprefix)/var-% $(hostprefix)/bin/mkfs.jffs2
-	$(hostprefix)/bin/mkfs.jffs2 -x lzma -b -e 131072 -p -r $< -o $@
+	$(hostprefix)/bin/mkfs.jffs2 -v -b -e 131072 -p -r $< -o $@
 
 
 ####### root-$gui.$fstype
Die Patches müssen in der oben aufgeführten Reihenfolge eingespielt werden.
Einige Teile des Patches stammen von Nikos Mavrogiannopoulos.

Hier einige Zahlen:
Dateigröße von vmlinuz:
nur jffs2 aktiv: 646383 Byte
jffs2+zlib: Zuwachs 16836 Byte
jffs2+lzma: Zuwachs 17959 Byte
jffs2+lzma+zlib: Zuwachs 34972 Byte

Ein Testimage zeigt folgende Füllstände für /var

jffs2+zlib: /dev/mtdblock/3 2.1M 656.0K 1.5M 30% /var

jffs2+lzma: /dev/mtdblock/3 2.1M 636.0K 1.5M 29% /var
Statistik von mkfs.jffs2:
Compressors:
none compr: 27 blocks (75306) decompr: 0 blocks
lzma (prio:70) + compr: 332 blocks (355081/773077) decompr: 0 blocks
Nachteil dieser Variante ist, dass durch das Fehlen eines lzma-Komprimierers
und des zlib-Supports unkomprimiert auf die JFFS2-Partition geschrieben wird.
Deshalb sollte neben lzma- auch zlib-Support im Kernel sein:

jffs2+lzma+zlib: /dev/mtdblock/3 2.1M 628.0K 1.5M 29% /var
Statistik von mkfs.jffs2:
none compr: 20 blocks (50159) decompr: 0 blocks
lzma (prio:70) + compr: 332 blocks (355081/773077) decompr: 0 blocks
zlib (prio:60) + compr: 8 blocks (24921/25147) decompr: 0 blocks
Einige Dateien sind also mit zlib besser komprimierbar als mit lzma,
der Kernel kann beide Dateien lesen.

Aufgefallen ist mir das, weil ich anfangs eine JFFS2-LZMA-ZLIB-Partition mit
einem JFFS2-LZMA-(ohne zlib)-Kernel lesen wollte, das ging bei den zlib-
komprimierten Dateien in die Hose ;)
$Id: cam.c,v 1.30 2004/01/10 16:36:34 alexw Exp $
JFFS2 compression type 0x06 not available.
Error: jffs2_decompress returned -5
cam: no firmware file found
Mit einem vollständigen Kernel war alles wieder in Ordnung...

Ich weiß, dass der Kernel größer wird als die hier sichtbare Platzersparnis in /var.
Das ganze ist eher als proof-of-concept zu verstehen als Vorstufe zu einem
reinen JFFS2-Image, das mit LZMA komprimiert wurde. Genau das habe ich
noch nicht geschafft, da U-Boot keine JFFS2-LZMA-Dateien lesen kann.

Ein weiterer Punkt auf meiner To-Do-Liste ist ein lzma- statt gzip-komprimierter
Kernel, der auf einer von U-Boot aktuell unterstützten Partition liegt. Für das
Entpacken eines lzma-komprimierten Kernels durch U-Boot gibt es Patches.
Zuletzt geändert von rhabarber1848 am Freitag 18. September 2009, 08:21, insgesamt 4-mal geändert.
Houdini
Developer
Beiträge: 2183
Registriert: Mittwoch 10. Dezember 2003, 07:59

Re: neues Dateisystem UBIFS für Flashspeicher

Beitrag von Houdini »

Ein weiterer Punkt auf meiner To-Do-Liste ist ein lzma- statt gzip-komprimierter
Kernel, der auf einer von U-Boot aktuell unterstützten Partition liegt. Für das
Entpacken eines lzma-komprimierten Kernels durch U-Boot gibt es Patches.
Das habe ich schonmal versucht, wenn ich mich noch recht erinnere bringt das einen ca. 100k kleineren Kernel (bei mir von 800 auf 700k) und einen >30 Sekunden Delay beim Booten weil das Entpacken ewig dauert...

Edit: oder hatt ich damals ein bzImage ausprobiert... :gruebel:
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Re: neues Dateisystem UBIFS für Flashspeicher

Beitrag von seife »

<klugscheiss>
bzImage ist *nicht* anders komprimiert. Ausserdem gibt es das nur auf x86, das hat irgendwas mit der Grösse zu tun, wenn das Kernel-Image zu gross ist, muss es anders geladen werden, wegen 640kB-Grenze etc... :-) Das ist dann das bzImage: "big zImage".
Ist heute Standard. Aber halt nur auf x86.
</klugscheiss>
rhabarber1848
CDK-Experte
Beiträge: 4335
Registriert: Donnerstag 3. April 2008, 14:05

Re: neues Dateisystem UBIFS für Flashspeicher

Beitrag von rhabarber1848 »

Houdini hat geschrieben:Edit: oder hatt ich damals ein bzImage ausprobiert... :gruebel:
Den Link suche ich jetzt nicht mehr raus, aber bei meinen Recherchen
habe ich Deinen Bericht gefunden, es ging in der Tat um ein bzImage.

Ich habe auch gelesen, dass LZMA und gzip schneller als bzip2 entpackt
werden können. Außerdem:
http://www.bitsum.com/openwiking/owbase ... imizations
There are people who would question the speed of the LZMA decoder. This is not an issue for the following reasons:

1. The small block size (4KB) means there is low computational and memory overhead for decompression (and also for compression, if we were adding LZMA encoding to the filesystem driver).
2. It's going to be much faster than SquashFs-lzma, since SquashFs-lzma uses 64Kb block sizes by default. These same people don't seem to complain about the speed of SquashFs.
rhabarber1848
CDK-Experte
Beiträge: 4335
Registriert: Donnerstag 3. April 2008, 14:05

Re: neues Dateisystem UBIFS für Flashspeicher

Beitrag von rhabarber1848 »

Solange U-Boot nicht mit einer JFFS2/LZMA-Partition klarkommt,
gibt es eine Alternative, die hier schon angesprochen wurde: upx.

Anbei der Patch für das Tuxbox CVS: EDIT: Patch ist im CVS
Dazu gehört ein glibc-Patch, der in normalen Images nicht schadet,
aber diese Fehlermeldung beim Start von upx-komprimierten
binaries behebt:
Inconsistency detected by ld.so: rtld.c: 288: _dl_start_final: Assertion `info->l.l_tls_modid == 0' failed!
Quelle des Patches: http://sourceware.org/ml/libc-alpha/200 ... 00064.html

Anwendungsbeispiel in einem customization-Skript:
root-neutrino-jffs2-local.sh

Code: Alles auswählen

make upx_host
for i in neutrino nhttpd sectionsd timerd tuxmaild zapit; do
        $flashprefix/../cdk/bin/upx --best --lzma $1/root-neutrino-jffs2/bin/$i
done
Zuletzt geändert von rhabarber1848 am Dienstag 7. Juli 2009, 19:27, insgesamt 1-mal geändert.
seife
Developer
Beiträge: 4189
Registriert: Sonntag 2. November 2003, 12:36

Re: neues Dateisystem UBIFS für Flashspeicher

Beitrag von seife »

Das Problem mit upx und anderen exe-komprimierern ist, dass das dann aus dem RAM läuft.
Das heisst dass immer das komplette Binary im RAM liegt und nicht nur die Pages, die benötigt werden.

Da würde ich lieber etwas Datenhygiene betreiben und nicht so viel Zeug ins Image packen.
rhabarber1848
CDK-Experte
Beiträge: 4335
Registriert: Donnerstag 3. April 2008, 14:05

Re: neues Dateisystem UBIFS für Flashspeicher

Beitrag von rhabarber1848 »

seife hat geschrieben:Das Problem mit upx und anderen exe-komprimierern ist, dass das dann aus dem RAM läuft.
Meine Box hat 64MB 8)
rhabarber1848
CDK-Experte
Beiträge: 4335
Registriert: Donnerstag 3. April 2008, 14:05

Re: neues Dateisystem UBIFS für Flashspeicher

Beitrag von rhabarber1848 »

rhabarber1848 hat geschrieben:Solange U-Boot nicht mit einer JFFS2/LZMA-Partition klarkommt,
gibt es eine Alternative, die hier schon angesprochen wurde: upx.

Anbei der Patch für das Tuxbox CVS: EDIT: Patch ist im CVS
committed:
http://article.gmane.org/gmane.comp.vid ... ox.scm/782
http://article.gmane.org/gmane.comp.vid ... ox.scm/783
http://article.gmane.org/gmane.comp.vid ... ox.scm/784
http://article.gmane.org/gmane.comp.vid ... ox.scm/785
Antworten