mini_fo-Addon

mini_fo ist ja nun schon seit geraumer Zeit im ds26 integriert und funktioniert (zumindest bei mir) hervorragend.

Macht es da nicht Sinn, die alte Idee wieder aufzuwärmen und das Filesystem des Mod entsprechend umzustellen? Die vielen Symlinks sind umständlich und unübersichtlich.

Es sollte doch kein Problem sein, die Änderungen am Dateisystem irgendwie im Flash abzulegen und persistent zu machen, oder bin ich völlig auf dem Holzweg?

Völlig auf dem Holzweg

Davon abgesehen, knallt man sich den doch sehr begrenzten Platz im TFFS schnell voll, wenn mini_fo darauf gemappt wird. Außerdem würde es potentiell ziemlich viele Schreibzugriffe geben aufs TFFS, wenn implizit immer geschrieben würde bei wahlfreiem Zugriff auf irgendeinen Teil des Dateisystems - auch nicht gut für die TFFS-Lebensdauer.

Bei OpenWrt und Freifunk Firmware ist auch / komplett beschreibbar, Änderungen werden persistent gespeichert und die Flash Lebensdauer ist kein Problem.

Mal vorneweg, wie es mit der Flash-Lebensdauer aussieht kann ich auch nicht sagen. Ansonsten muss man leider differenzieren. Es gibt wie es olistudent angedeutet hat leider keine Linie, die man konsequent verfolgen kann. Auf das read-only SquashFS kann man nicht verzichten, da es eine sehr starke Kompression erlaubt, die man von RW Dateisystemen nicht bekommt. Weiß nicht wie es zur Zeit bei OpenWrt aussieht, mein letzter Stand ist ein SquashFS und als root Dateisystem ein JFFS2 Dateisystem, welches initial mit Symlinks auf das SquashFS gefüllt ist. Änderungen erfolgen dann im JFFS2 Dateisystem. Ich habe das jedoch nur gelesen und nie Live angeschaut. Mir gefällt die Lösung nicht besonders.

Nun könnte man natürlich mini_fo dazu benutzen, das SquashFS mit einem JFFS2 zu überlagern, welches den Platz nutzt, der vom SquashFS nicht benötigt wird. Sicherlich ein eleganter und flexibler Weg. Das größte Problem ist, dass mini_fo veränderte Dateien komplett kopiert und eine einmal veränderte Datei nie mehr aus dem beschreibbaren Dateisystem verschwindet, auch wenn sie nach einer weiteren Veränderung wieder exakt gleich ist. Das Dateisystem müllt immer mehr zu. Gut nach einem Firmwareupdate wird eh wieder alles gelöscht und von vorne begonnen. Auf der 7050 ist aber zum Beispiel garnicht genug Platz mehr, um mini_fo mit einem JFFS2 sinnvoll zu benutzen. Daher bleibt das ganze leider wohl immer nur ein Zusatzfeature. Um nicht unnötig Schreibzugriffe zu haben, würde ich /var auch immer flüchtig lassen.

Was macht man also mit den Boxen, die nicht genug Flash haben? Ein externes Medium als mini_fo Storage ist auch keine so gute Idee, solange nicht jedem klar ist, dass auch das alles gelöscht wird, wenn man ein Firmware Update macht. Das private Fotoalbum sollte daher auf jede Fall in einem unabhängigen Dateisystem lagern.

Mfg
danisahne

Oliver hat mir mal ein funktionsfähiges Init-Skript für mini_fo + JFFS geschickt, das ich allerdings trotz genügend freien Platzes nicht ausprobiert habe. Ist lange her, aber ich habe es noch. Evtl. stammt es ja auch von Dir (Daniel) oder Enrik, so genau weiß ich das nicht. Aber die genannten Nachteile (ganze Dateien, nie löschen) von mini_fo stören mich bereits in der RAM-Disk. Gibt es ein Overlay-FS, welches da geschickter vorgeht und das vom Footprint her ähnlich schmal ist? Wobei ich hinzufügen möchte, daß mini_fo absolut stabil läuft, wenn man es nicht noch mit nfsroot mischt, was laut Oliver nicht klappt.

Also z.B. ein Siemens SE505 hat auch "nur" 8MB Flash und die Freifunk Firmware (mit SquashFS + JFFS2) läuft einwandfrei.

Ich verstehe noch nicht wirklich, wieso dieses Verfahren für die Fritzboxen ungeeignet sein soll, bzw. was Daniel daran nicht gefällt?

In der Regel gibt es ja auch nicht so viele Änderungen am Dateisystem.

Ich denke, das Problem mit dem "nur 8 MB Flash" bezieht sich vor allem darauf, dass die Fritzboxen nicht nur WLAN-Router sind, sondern auch noch Telefon-, VOIP- und sonstige Dienste beinhalten, und dass der Flash-Speicher mit der Firmware an sich schon sehr voll ist (und im Falle der 7050 z.B. es teilweise schon problematisch ist, den DS-Mod überhaupt drauf zu bekommen). Für die verbleibenden paar Bytes macht es dann wohl wenig sinn, ein mini_fo zu installieren, was selbst auch noch Platz wegnimmt.

Daniel hat doch erkklärt, weshalb das Verfahren ihm nicht gefällt, ich bin auch nochmal darauf eingegangen, daß mini_fo Nachteile hat. D.h. nicht, daß es nicht funktioniert. Er hat ebenfalls erwähnt, daß die 4-MB-Boxen im Normalfall nicht genügend Platz dafür haben. Er hat auch nicht gesagt, daß man es nicht nutzen könnte, sondern daß es immer ein optionales Feature bleiben würde, denn auch bei den 8-MB-Boxen hängt es doch allein von der Paketitis des Anwenders ab, ob und wieviel Platz er noch hat. Das ist nicht zuverlässig, es sei denn, wir würden die Maximalgröße von kernel.image derart begrenzen, daß zumindest ein gewisser Anteil des Flash-Speichers für JFFS frei bliebe. Und ob es "in der Regel nicht so viele Änderungen am Dateisystem" gibt, hängt auch rein von der Konfiguration und der Art der Nutzung ab. Ich sehe jetzt schon die Support-Calls auf mich zu kommen, bei denen unerfahrene Nutzer ins JFFS loggen oder große Pakete dorthin kopieren, weil sie ja ein transparent beschreibbares Root-FS vor sich haben. Klar, mit mini_fo im RAM ist das auch so, aber dort ist normalerweise auch mehr Platz frei. Wenn denen der Speicher überläuft oder sie sich eine geänderte Datei zerschossen haben, macht die Box einen Reboot und das System ist wieder sauber. Zerschieß Dir etwas via JFFS, und es wird fein säuberlich wieder darüber gemountet beim Booten, nichts geht mehr.

Ich will damit Daniel unterstützen, indem ich ebenfalls dafür plädiere, mini_fo + JFFS optional als Add-On oder maximal als Paket zu machen, aber ohne deswegen sämtliche knapp 100 anderen Pakete komplett so umzustellen, daß sie plötzlich z.B. direkt Dateien in /etc ändern. Auf dessen Beschreibbarkeit können sie sich genauso wenig verlassen wie beim ebenfalls optionalen mini_fo + tmpfs.

Für die 8Mb Boxen ist geht es sicherlich gut, aber es muss im Mod optional bleiben, weil es beispielsweise für die 7050 und die ganzen 2mb Boxen ungeeignet ist. Wenn man oft genug ein Firmware-Update macht, dann sind die Nachteile nicht so gravierend.

Mich stört ja gerade, dass man keine einheitliche Linie verfolgen kann.

Mfg
danisahne

Ich habe in mein aktuelle ds26-15.2 mini_fo mit reingepackt und es läuft soweit auch. Aber nun stell ich mir die Frage:
Wie kann ich eine Partition meines Sticks über das root-Dateisystem legen?

Das Paket installiert auch ein Init-Skript, welches die RAM-Disk übers Root legt, und zwar gleich beim Booten. Danach kann das auch nicht mehr deaktiviert werden. Was Du möchtest, ist etwas anderes, nämlich eine Art persistente Überlagerung mit einem Speicher, der auch einen Reboot überdauert. Dazu müßtest Du das Init-Skript anpassen, und das ist nicht trivial. Eine schnelle Lösung habe ich dafür nicht, denn es ist ja erforderlich, daß erst mal der Stick zugänglich ist, also die entsprechenden Filesystem-Module geladen sind und der Stick gemountet wird. Erst danach kannst Du mit der Überlagerung anfangen. Also entweder modifizierst Du das Init-Skript aus dem Paket oder Du läßt das Paket weg, nimmst nur das Modul mini_fo.ko rein und schreibst Dir was eigenes. Um eine Lektüre der Doku und ziemlich viel Probiererei wirst Du dabei nicht herum kommen. Schwierig hierbei ist, daß Du das Root-FS so früh wie möglich überlagern mußt, also bevor aus dem Original-Root die zu überlagernden Dateien im Zugriff sind - und das ist tricky. Wie gesagt, schau unser Skript mini_fo.rc an.

Also wenn das alles so kompliziert ist, dann lass ich es. So viel Zeit habe ich auch wieder nicht. Aber danke trotzdem für die Erklärung. Vielleicht kommt ja irgendwann noch das überlegte mini_fo für die Nachinstallation auf USB/Netzwerk als Paket?