neues Dateisystem UBIFS für Flashspeicher

[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]

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]

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]

UBIFS ist eher für die aktuellen USB-Sticks bzw. deren Flashgrößen interessant. Die 8MB der dbox2 sind da eher Kinderkram
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]

Aktiviert doch LZMA in euren JFFS2 Images

http://home.arcor.de/audioslyer/jffs/li ... lzma.patch
http://home.arcor.de/audioslyer/jffs/mt ... lzma.patch

Gruß
AS

[seife]

Ich schreibe hier lieber nicht, was die Filesystem-Leute zu den LZMA-Patches gesagt haben

[rhabarber1848]

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]

dann schaue man sich mal den Code vom LZMA an dann kann man sich denken was andere dazu sagen würden ...
Umsonst ist der noch nicht im Kernel enthalten.

[AudioSlyer]

Dann verschönert ihn mal, passt doch zum Neutrino
Bei mir rennt das JFFS2-LZMA seit 4 Monaten ohne Probleme.

[rhabarber1848]

Bei mir rennt das JFFS2-LZMA seit 4 Monaten ohne Probleme.

Wieviel Prozent bringt die LZMA-Kompression in Deinem Fall?

[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]

Man schreibt ja nicht ständig was in den Flash, daher ist die Geschwindigkeit nicht ausschlaggebend.

[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]

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]

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

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.

[rhabarber1848]

Aber um es testen zu können müsste es jemand lauffähig machen.

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.

[rhabarber1848]

http://home.arcor.de/audioslyer/jffs/li ... lzma.patch
http://home.arcor.de/audioslyer/jffs/mt ... lzma.patch

Hast Du schon ein JFFS2/LZMA-Image mit U-Boot gestartet?

[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.

[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...

[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]

Edit: oder hatt ich damals ein bzImage ausprobiert...

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]

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

[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]

Das Problem mit upx und anderen exe-komprimierern ist, dass das dann aus dem RAM läuft.

Meine Box hat 64MB

[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

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