Erstens das und Ihr vergesst das Marsu auch dafür da ist um Images mit ubifs zu sichern, nicht nur für die Konvertierung.

Letztendlich wird das Marsupilami aber wieder im Dschungel verschwinden und die ubifs Sachen Einstellungen im normalen dFlash sein.

Bis das aber soweit ist und alles stabil funktioniert ist es mit einem Standalone Plugin nur fürs ubifs einfacher zu handeln für mich und weniger verwirrend für die User.

PS: wenn Ghost noch fade ist am Wochenende könnte er noch einen aktuelleres mkfs.ubifs bauen lassen, weil der fix für das sichern das mit realpath überprüft wird ob das sicherungsdirectory nicht Teil der root ist wurde ist erst im Herbst eingechecked und daher ist das mkfs.ubifs aus dem Feed eigentlich unbrauchtbar. Außerdem sollte er bei den squashfs Images auf 500hd und 800se das compression Flag nicht mehr setzen, im ubifs ist das kontraproduktiv wenn du ein squashfs versuchst 'besser' zu komprimieren. Und man könnte auch selektiv bei performancesensitiven files wie libs und dem enigma2 binary das compression Flag ganz wegnehmen, bringt performance und der Mehrbedarf an Platz ist auf der 8000 und 7020hd zu vernachlässigen. ubifs ist deutlich modernen und kann solche sachen, auch das read ahead wäre bei den großen libs überlegenswert.

LG
gutemine

Jo, bis auf weiteres ...

Das ist doch ne klare Antwort.

Danke gutemine

G

Also die 1.0 von Marsu sichert jetzt mit den Default Einstellungen die Images so wie von DMM vorgegeben, die ganzen Einstellmöglichkeinten wie andere Compression sind aber weiterhin da (und auf der 500hd und 800se auch nötig) und man kann auch auf der 7020hd den Platz zwischen root und data volume beliebig hin und her schieben. So sieht es z.B. mit 600 MB root size statt den 397MB aus (und an der Bootzeit ändert sich dadurch kaum was):

df -h

Filesystem Size Used Available Use% Mounted on

ubi0:rootfs 542.9M 85.3M 457.6M 16% /

Bei der Version 1.1 von Marsu geht jetzt wieder Konvertierung und Sicherung und das
Ergebnis einer Konvertierung sollte praktisch ident zu den im OE
gebauten UBIFS Images sein und es wurden auch eine Menge andere bugs
gefixed, und auch Sachen eingebauut wie fehlende /boot und /data Mounts
in die fstab nachzutragen, etc.

Bitte Testet das AUSGIEBIG weil erst wenn es 100% funktioniert darf
Marsu zurück in den Dschungel und die Funktionen fürs ubifs wandern ins
dFlash.

Viel Spass mit Marsu!

LG
gutemine

Hi !

Ich musste den Thread leider wieder auf fast gelöst setzen.

Am Wochenende habe ich versucht auf der 500hd und der 800se ubifs von einem block2mtd device zu booten. Bis jetzt hatte ich ja nur block2mtd devices benutzt die entweder read only gemountet wurden (um mit nfidump das ubifs aus einem nfi image zu entpacken) oder die eben genauso groß waren wie im Flash.

Jetzt gibg es aber darum die images der 500hd und 800se auf USB oder SATA auf mindestens 256MB aufzublasen und davon beschreibbar zu booten und dabei bleibt mir die box immer beim beschreibbaren mounten des ubifs hängen, und zwar nicht beim ubiattach sondern beim Fixup des Freiplatzes beim ersten Mounten (das -F beim mkfs.ubifs setzt ja das Flag damit die Flashgröße nicht fix ist).

Es hat mich Stunden (und eine Menge debug output) gekostet, um rauszufinden woran das liegt, und letzendlich hat sich gezeigt das es ein bug im block2mtd.c ist, der aber schon im Vorjahr gefixed wurde, wenn auch in einem anderen Zusammenhang.

Ich würde also auch noch diesen Patch eingechecked benötigen:

http://patchwork.ozlabs.org/patch/161039/

Im Prinzip geht es nur darum das sich der block2mtd das mtd_writev nicht mehr selbst setzt, weil das sonst zu einer Endlosloop führt.

Ja ich weis, nicht schon wieder ein kernel Update und das auch noch wegen nur einer Codezeile, aber ich kann halt nicht alles auf einmal testen und scheinbar ist niemand so pervers statt dem nandsim den block2mtd zu verwenden, aber nachdem wir den nun mal schon im Kernel haben mache ich mir halt die Mühe.

Aber erst wenn das auch noch eingechecked ist kann ich mit rambo weitermachen, weil das macht nur Sinn wenn alle Images das auch mit ihren Kerneln können.

LG
gutemine

gutemine ist geduldig

Ich habe ja noch genug andere Sachen zu tun, und ich kann mir ja den Kernel selber mit entsprechend gepatchtem block2mtd driver bauen. Die user sind da eher die lästigen die dann fragen warum dieses oder jedes noch nicht geht.

Ich habe für die ubifs umstellung jetzt schon mehr als 2 Wochen Aufwand reingebuttert, insofern bin ich auch nicht böse wenn ich manche Sachen nach hinten schieben kann.

Andererseits sind es keine 15min um den Patch einzuchecken, testen wird das eh keiner, weil der Einzige der den block2mtd Treiber wirklich verwendet bin eh ich. Das Teil ist mehr oder weniger totes Gebiet was die Entwicklung angeht und die meisten Bugs sind eh schon längst bekannte Patches die halt nötig sind für die speziellen Anwendungsfälle die mir halt so einfallen wenn mir gerade fade ist.

Andererseits gibt es kein einfaches ubifs extract tool und ich hab das nfidump jetzt so hingezimmert das es mit Umweg über eben den block2mtd ohne das der user es merkt jedes ubifs (auch von den Fremdoxen) entpacken kann ohne das man sich mit nandsim quälen muss.

Das booten vom block2mtd mit rambo ist halt für die user erschreckend einfach - 1 Binary, 1 (nfi) File und schon kannst du mit ubifs den 'Flash' beliebig groß haben und wenn du neues nfi hinkopierst wird das 'geflasht' und gebootet.

Auerdem performt es sogar besser als echter Flash, erst recht wenn man es aufs rawdevice loslässt statt ein file im Filesystem zu machen, aber soweit sind wir halt noch nicht

Insofern bin ich halt geduldig und zur Not kann ich immer noch OoZoon bitten es mir vorab in sein Image reinzumachen, so haben wir ja auch die Patches die Anfang der Woche eingechecked wurden getestet, um sicher zu sein das Sie funktionieren wie sie sollten.

LG
gutemine

Letzter Aufruf für das booten vom block2mtd device, sonst muss ich wirklich OoZoon quälen das er mit den Patch in sein Image vor-ab reinmacht.

Übrigens noch eine Frage dazu - theoretisch kann man mit der entsprechenden Kernel Commandline auch ohne rambo von einem sata oder USB device booten wenn man das ubifs roh ohne filesystem aufs /dev/sdb1 schreibt und dem Block2mtd treiber sagt das er damit ein Flashdevice machen soll. Das performt sogar besser als der Flash weil es das ganze Wear Level handling, etc. da ja nicht gibt weil es ja kein echter Flash ist und den Overhead des Filesystems spart man sich dann auch.

Bestünde Interesse das als Plugin anzubieten ?

LG

gutemine

Wenn wir schon so schöne Monologe führen, könnte man beim mkfs.ubifs.c auch ein paar Patches ins OE einpflegen ?

Erstens bitte einen aktuellen Snapshot der mtd-utils sourcen verwenden damit auch die ganzen ubi utilities endlich aktuell sind.

Zweitens den Patch der die xz compression beim mkfs.ubifs hinzufügt (weiter oben im Thread), allerdings nicht vergessen den Default compression Level im compression.c von 9 auf 4 zu reduzieren, sonst geht der Dreambox das Memory aus beim Extrahieren des Ergebnisses.

Drittens der Patch der es erlaubt directories zu excluden wäre auch nett:

http://patchwork.ozlabs.org/patch/166053/

Ich mache zwar jetzt beim Sichern immer einen bind mount der root, um die mounts loszuwerden, einfacher wäre es aber wenn man analog zum mkfs.jffs2 --ignore-path Patch diesen mkfs.ubifs -z Patch auch rein machen würde.

LG
gutemine

Irgendwie hätte ich den Witz mit dem Pilze/Patches Sammeln nicht machen sollen

ich habe mal ein bisschen die Performance vom Block2mtd Treiber mit ubifs unter Last getestet, und bemerkt das wenn man wirklich große devices macht (was bei rawdevices aber leicht passieren kann) anfangs ziemlich viel Memory benötigt wird, bis die box einfriert, weil wenn sehr viel IO passiert wie z.B. beim ersten boot wenn das Fix Freespace gemacht wird die box nicht mehr weis was sie mit den ganzen Page Updates machen soll.

Damit die box dabei eben nicht einfriert braucht man auch noch diesen Patch im block2mtd.c der das Memory Management vom Linux in den Hintern tritt:

http://lists.infradead.org/pip…2012-December/045271.html

Wenn ich mit dem Patch meiner 500hd ein 400MB großes root ubifs spendiere damit sie vergleichbar zur 7020hd Platz hat, dann dauert der erste mount rund 2 1/2 min und ab dann ist es beim booten genauso wie echter Flash in wenigen Sekunden gemountet. Ohne den Patch bleibt die box einfach hängen beim ersten mounten. Und bei 256MB großem root filesystem sind es nur knapp 1 min Mountzeit beim ersten boot.

LG
gutemine

Na ja das sind Standard Patches die von den mtd Devs abgezeichnet wurden, insofern ist das keine große Sache.

Aber ich bin eh geduldig ... nur die User sind es oft nicht.

PS: Wird sind hier in der Developer Ecke, die Plugins die das brauchen sind eine andere Geschichte.