Hi !

Eigentlich wollte ich nachdem dankenswerterweise ubifs ins git eingechecked wurde erstmals Ruhe einkehren lassen, schon weil ich genug mit der Anpassung meiner Tools und Plugins zu tun habe.

Nachdem ich mir aber jetzt überall anhören muss, dass ubifs für die kleinen Boxen mit nur 64Mb nicht geeignet ist, habe ich mir das ein bischen genauer angeschaut, schon weil ja seit SqueezeOut bekannt sein sollte, das ich auch die squashfs Lösung im jffs2 nicht gerade für ideal halte, wenn auf diese weise koste es (Performace) was es wolle, die ganzen Sachen in den kleinen Flash gestopfet werden.

Vor allem weil es ja eigentlich nicht das squashfs ist welches dabei die Lösung bringt, sondern die lzma compression (oder xz wie sie jetzt heisst seitdem sie im Standard ist).

Im Gegensatz zum jffs2 wo man das wohl wirklich nur mehr mit den so beliebten squashfs files und den loop mounts lösen kann ist ubifs aber ein deutlich moderneres Filesystem das auch kontinuierlich erweitert und verbessert wird. Es gibt daher für ubifs auch Patches die native xz compression ermöglichen:

http://enduser.subsignal.org/~trondah/tree/tools/mtd-utils/patches/136-mkfs.ubifs-xz-support.patch

https://dev.openwrt.org/browse…compression-support.patch

(die bei OpenWRT haben ja ein ähnliches Problem mit der Flashgröße)

Ich habe mir den Patch fürs mkfs.ubifs mal testweise in ein entsprechendes mkfs.ubifs binary gemacht, das dann auch mit der -x xz compression option das ubifs bauen kann, und wenn man so das root filesystem der Dreambox sichert kommt ein um > 5MB kleineres Ergebnis raus als wenn man zlib als compression nimmt.

Das Image kann man natürlich jetzt nicht einfach booten weil noch der Patch im ubifs Filesystem fehlt um diese mit xz komprimierten einzelnen Files auch dekomprimieren zu können, aber nachdem genau mit diesen 'fehlenden' 5MB argumentiert wird, warum man ubifs nicht auf den kleinen Boxen haben kann, würde ich bitten darüber wenigstens mal nachzudenken, weil so viel Aufwand xz compression fürs ubifs auf die kleinen Dreamboxen zu bekommen wäre das nicht, da ja der Code aus den vorhandenen Patches weitestgehend übernommen werden kann (obwohl ich auch gekämpft habe bis wenigstens das mkfs.ubifs mit xz komprimieren konnte) Und die squashfs Files könne man dann auch wieder entsorgen.

LG
gutemine

Dann compiliert mir die ubifs Treiber mit xz Support, so schwer ist das auch wieder nicht auch wenn die Versionen nicht ganz zusammen passen.

Nachdem praktisch alle 'großen' Files im OE im Normalbetrieb nur read only sind und nur bei einem Upgrade ersetzt werden und man im ubifs auch noch auf Filebene steuern kann welche files komprimiert werden sollen und welche nicht lässt sich damit viel schöner und selektiver der Platz im Flash benutzen. Und nachdem wir ja aus den Cramy Tests wissen das man wenn man das GANZE image als squashfs gepackt hat, auf USB/SATA rausgeschoben und den Flash nur mehr für das delta benutzt hat (so wie das Live CDs machen) solche Squashfs images < 40MB waren lehne ich mich auch nicht sehr weit raus wenn ich sage das es sich trotz ubifs Overhead ziemlich genauso gut wie mit jffs2+squashfs mit dem Freiplatz auch in den 60MB root ausgehen sollte.

LG

gutemine

das alte lmza1 ist nicht das selbe wie lzma2 das jetzt eben xz heisst, insofern darf man da nicht beides in den selben Topf tun. Nicht umsonst funktionieren die squashfs images im OE 2.0 besser als das was wir in der 7025 hatten.

Und das ganze hat eine Highwater Mark wenn ich es recht verstanden habe - kleine Files werden sowieso nicht mit xz komprimiert (selbst bei lzo bleiben die oft none), das wird erst ab einer gewissen Größe gemacht damit es auch was bringt. Die RW dateien sind ja meistens klein und haben nur irgendwelche einstellungen, settings,.. die sind nicht am Platzproblem schuld, sondern die libs und die binaries und die werden nur beim Uodate getauscht. Und da ist es mir egal ob der update 1 oder 3 minuten dauert wenn das Ergebnis stimmt. Man könnte sogar lügen und die binaries bereits im OE mit squashfs komprimieren und so in die ipks packen und dann das compression none attribute im filesystem setzen das sie so wie sie sind im ubifs landen und nur bei Zugriff vom ubifs mit xz support dekomprimiert werden, dann ist ein Upgrade sogar schneller wie mit den anderen compressions.

Und wenn man z.B ein enigma2 binary durch xz jagt hat man fast 1 MB mehr und es kostet nicht mal eine Sekunde startzeit wenn man es dann anwirft. Ich habe mit Cramy das GANZE enigma2 in ein squashfs mit xz gepackt und von USB/SATA geladen (und nur die Deltas in den Flash gemacht) und das hat ganz normal performt, insofern denke ich schon das es funktionieren würde.

Dr. Chaos hat mir jetzt einen Kernel mit XZ im UBIFS gemacht, ich muss mal sehen ob ich es damit zum Laufen bringe dann könnt Ihr es selbst ausprobieren.

Und der ubifs Overhead ist ja das gute daran, weil es dadurch skaliert und performt - das ist wie Spoiler beim Auto die zwar gut aussehen aber halt auch Sprit kosten.

LG

gutemine

Jo sorry

Du hast es aber zusammen mit dem lzo aufgedreht, oder nur none + xz als UBIFS compression ?

OK, das wäre perfekt, weil dann kann ich das mkfs.ubifs so hacken wie ich will um die files mit allen 3 Compression rates möglichst performant zu komprimieren.

Nur muss ich dann die Logik für die Compression auswahl im mkfs.ubifs noch entsprechend anpassen, der Patch den ich jetzt habe ist dafür zu simpel. Aber ich probiers einfach mal mit dem maximum aus, dann sieht man wenigstens schon mal wo man Größenmässig rauskommt und im Moment wissen wir ja noch nichtmal ob das dann noch bootet.

LG

gutemine

Dr. Chaos was gestern abend sehr fleißig und hat einen Kernel mit xz Support für die 7020hd zustandegebracht (dort kann man mit dem 2. data volume am leichtesten testen).

mount -t ubifs -o compr=xz /dev/ubi0_1 /data

dmesg

[ 475.389000] UBIFS: un-mount UBI device 0, volume 1
[ 495.904000] UBIFS: mounted UBI device 0, volume 1, name "data"
[ 495.905000] UBIFS: file system size: 599326720 bytes (585280 KiB, 571 MiB, 2360 LEBs)
[ 495.906000] UBIFS: journal size: 29966336 bytes (29264 KiB, 28 MiB, 118 LEBs)
[ 495.907000] UBIFS: media format: w4/r0 (latest is w4/r0)
[ 495.907000] UBIFS: default compressor: xz
[ 495.908000] UBIFS: reserved for root: 4952683 bytes (4836 KiB)

Jetzt ist das mkfs.ubifs mit -x xz an der Reihe, mal sehen was der Abend so bringt.

PS: Den ubifs Patch für die compr= mount option beim ubifs könntet Ihr auch unabhängig vom xz ins ubifs reinmachen, der ist in jedem Fall eine Bereicherung, im jffs2 habt Ihr den ja auch drinnen.

Danke, weil mit dem kann man die root auch mit zlib statt lzo mounten wenn der Platz knapp wird, oder auch mit none wenn einem der Platz egal ist - mit Marsu kann man ja die Größe auf der 7020hd zwischen root und data frei verschieben.

Danke fürs Ausprobieren.

Das mkfs.ubifs mit xz support mit dem Standard Patch ist ein bisschen zu simpel implementiert, sobald ein file zu klein ist oder durch das komprimieren größer als vorher nimmt es none als compression. Ich habe das in der Zwischenzeit analog zur favor_lzo routine so umgebaut, das er einfach alle 4 compressions ausprobiert und dann das beste Ergebnis nimmt. Damit findet man nochmals 1-2MB, je nachdem was man ins Image packt. Und ja, wenn man die squassfs images weglässt komme ich auch nur mit Heulen und Zähneklappern auf <60MB (was aber eh schon ziemlich gut ist wenn das gleiche image mit jffs2 und zlib 80-90MB ist).

Wobei die 43,1MB was mein best-of bis jetzt war nicht so schlecht sind, man hat dann rund 8MB Freiplatz im Flash was im Prinzip mit dem jffs2+squashfs vergleichbar ist und nachdem ubifs bei Upgrades nicht so stark fragementiert wie das jffs2 sollte man dann auch einen Upgrade überleben können.

Das echte Problem das ich bei meinen Tests gestern gemerkt habe ist gar nicht so sehr die zeit die es zum Erstellen braucht (Zeit ist seit Einstein ja relativ zu sehen), sondern der Memory Verbrauch.

http://www.gsp.com/cgi-bin/man.cgi?topic=lzma

Die Liste was den Memory Verbrauch angeht ist leider ziemlich realistisch, womit man eigentlich auf den kleinen Boxen nur bis compression 4-6 gehen kann damit man die Files on the fly auf der box mit dem xz Support im ubifs auch dekomprimieren kann. Dann ist es auch am PC zwar deutlich schneller erstellt (und braucht kein GB Memory zum Komprimieren) NUR sind dann die 2MB Platz wieder weg und wenn es nur 2-3MB kleiner ist als wenn man zlib nimmt lohnt sich der Aufwand nicht wirklich, da schmeißt lieber noch Sachen wie unnötige Sprachen aus den images, etc.

Aber mal sehen, ich habe mir noch das ganze Wochenende als Zeithorizont zum Spielen gesetzt, und nachdem das mkfs.ubifs eh immer so lange läuft kann man das schön nebenher machen.

Wenn man halt Sachen nicht ausprobiert weis man auch nicht 100% ob sie brauchbar sind, und ich spiele halt gerne mit dem Essen

LG
gutemine

Ich war am Wochenende beschäftigt mit dem ubifs Auspacken fürs nfidump (war mehr Arbeit als ich dachte wegen den nötigen Patches für den block2mtd Treiber, die jetzt aber dankenswerterweise im OE eingechecked sind). Nachdem zusammen damit auch der xz Support heute eingechecked wurde müssten wir jetzt alles haben damit es auch verwendbar ist.

Ich werde mal sehen ob ich das mkfs.ubifs so hinbringe das man damit auch ohne die box vom Memory beim dekomprimieren in die Knie zu zwingen auch noch entsprechend Platz im Flash finden kann, weil wie schon gesagt wenn man am PC Zeit hat ist es zwar möglich das Image noch kleiner zu kriegen, aber die so hoch komprimierten files müssen auch auf den kleinen Boxen wieder auspackbar sein, sonst bringt das leider nichts.

Derzeit stecke ich noch bei XZ compression Level 3-4 fest was nur maximal 1-2 MB mehr bringt als zlib und sobald ich es höher drehe kommen massig XZ Memory Allocation Fehler beim booten und das war es dann. Wenn die box mal läuft und ich swapfile aufdrehe um die Spitzen abzufangen dann kann ich auch ubifs mit höheren xz Compression raten mounten und drauf zugreifen, nur kostet das wieder etwa 10 sekunden wenn ich dann z.B. in der chroot dorthin enigma2 starte.

Insofern haben wir aber noch eine 50:50 Chance das es vielleicht so funktioniert wie ich mir das vorstelle, und mehr als probieren kann man es eh nicht.

Nur ist es halt mühsamer als ich dachte, aber das bin ich ja schon gewohnt

LG
gutemine

Nachdem ich es bei OoZooN im Board ausführlicher geschrieben habe hier nur die Kurzfassung.

Mit XZ compresion kriege ich weil man praktikabel nur bis ca. Compression Level 4 gehen kann ein OoZoon Image so hin das es rund 6MB Freiplatz hat (im jffs2 sind es 16MB). Ohne Squashfs geht es aber nicht, da fehlen mir einfach in jedem Fall je nach Kompression 2-5MB das es überhaupt in den Flash passen würde ohne schon beim booten zu platzen, und das würde ja auch nichts bringen wenn nicht wenigstesn die berühmten 5MB frei wären damit man es überhaupt upgraden kann..

Wahrscheinlich mache ich erstmals XZ also nur als mögliche weitere Compression ins Marsu rein um die Images zu konvertieren (muss man aber Geduld haben) und dann sehen wir weiter ob den Leuten der Platz reicht. Weil wenn man mit SqueezeOut Platz schafft geht auch ein mit zlib komprimiertes OoZooN mit ubifs relativ locker in den Flash.

Das Originalimage würde man aber so auch nicht in den Flash kriegen mit ubifs selbst wenn man das Squashfs drinnen lässt, weil der Freiplatz wäre zu gering, wenigstens so wie bei OoZooN müssten dafür Sachen wie samba raus. Dankte trotzdem erstmal allen für die Unterstützung und Hilfe beim Zusammensuchen und Einchecken der nötigen Sachen.

LG
gutemine