Die Remove-Patches sind wirklich "a pain in the ass" ... aber AVM bemüht sich ja auch redlich, sie dazu werden zu lassen.
Ich habe mir letztens auf einer 7270v3 das Log komplett zugemüllt, weil ich mich nur erdreistete, einen Service nicht zu starten (den aha-Daemon in S78-aha) ... da war noch nicht mal der Gedanke an ein "remove" im Spiel. Trotzdem kriegte sich die Box fast nicht mehr ein ... irgendwas mit Lua und AHA lt. Nachricht, genau weiß ich es nicht mehr.
Das einzige, was bei solchen Patchereien vielleicht helfen kann, ist das Ändern der CONFIG-Variablen und dann erst mal das geduldige Beoabachten, ob solche Bestandteile (im zweiten Schritt dann mal durch Wrapper mit Protokollierung ersetzt) auch wirklich nicht mehr aufgerufen werden.
Das ist nicht nur undankbar, das ist wegen der engen Verzahnung einiger AVM-Komponenten auch ein nahezu endloses Spiel. Das war früher schon wg. der geringeren Anzahl von Komponenten (und damit der möglichen Abhängigkeiten/Vernetzungen untereinander) leichter, heute ufert so etwas exponentiell aus und ich habe schon lange das Schielen auf "remove"-Patches aufgegeben.
Ich habe bei fritzbee21 nur deshalb nach dem Wert gefragt, weil es auch ohne den Verlust irgendeiner AVM-Funktion problemlos möglich ist, rund 250 KB zu "finden" (wenn ich mich richtig erinnere, der Wert ist nur geschätzt), indem man den Standard-Inhalt für den NAND-Flash einfach ausläßt. Das gibt es zwar auch als Bestandteil eines "remove"-Patches (ich glaube es war NAS), aber das ist tatsächlich risikolos und vollkommen ohne das Entfernen irgendeiner anderen NAS-Funktion machbar.
An der "Geschwindigkeit" des NAND-Flashs dürfte (neben dem Dateisystem vielleicht, wobei yaffs2 nun nicht sooo schlecht ist, ist ja eigentlich für Flash-Speicher konzipiert, was bei ext2 erst der Controller im Stick wieder über diverse Mechanismen ausgleichen muß) eher die Zugriffsmethode Schuld tragen, wenn ich das richtig in den Quellen lese (die wegen der verschiedenen Architekturen auch nicht allzu übersichtlich sind).
Da wird wohl nur ein "Fenster" in den Speicher gemappt und dann muß immer erst die richtige Flash-Page in diesen Bereich eingeblendet werden - so ein bißchen wie früher beim EMS auf dem PC. Allerdings ist es mir auch mit dem langsamsten NAND-Flash noch nicht passiert, daß ein Watchdog deswegen zugeschlagen hätte ... da begreife ich den Mechanismus nicht so recht, der dazu führen könnte. Höchstens noch extrem langsame Zugriffe auf eine "memory mapped"-Library o.ä. fallen mir da ein ... das müßte aber tatsächlich schon extrem sein und dann eine Lib, die nicht gemeinsam genutzt wird, denn die dürfte sich zum überwiegenden Teil dann schon im Speicher befinden.
Das einzige, was man bei einer 7390 definitv nicht machen sollte (auch wenn es verführerisch sein mag), ist das Anlegen eines Swap-Files im NAND. Das ist tatsächlich so gähnend langsam, daß da u.U. einige Komponenten die Watchdogs nicht mehr ruhigstellen können, wenn sie erst noch auf das Einlagern des dazu notwendigen Codes warten müssen und der tröpfchenweise aus dem NAND-Flash kommt.
Das heißt natürlich nicht, daß ein schneller USB-Stick nicht schneller sein kann als der NAND-Flash ... aber die USB-Schnittstelle der FRITZ!Box ist nun auch nicht die flinkeste und vom theoretischen Maximum (auch für USB2 mit dem bekannten Designproblem beim Mass-Storage-Protokoll) meilenweit entfernt, egal was das angeschlossene USB-Gerät an anderen Hosts zu leisten vermag.
Wenn man eine Chance dazu im eigenen Netzwerk hat, ist nach meiner Erfahrung tatsächlich ein NFS-Mount das schnellste, sogar mit dem nbd-Client (der ist in einigen Firmwares enthalten, ob bei der 7390 weiß ich gerade nicht) kann man ziemlich guten Durchsatz erzielen, wenn das verwendete Filesystem nativ im Kernel läuft.
Solange es am Ende nur um einzelne Binaries geht, macht auch ein Kopieren vom NAND-Flash in den RAM noch Sinn, wenn die Box genug Hauptspeicher hat.
Wenn es nur um OpenVPN geht, würde ich persönlich sogar komplett auf Freetz im Image verzichten, das ist ja nun im Handumdrehen zu Fuß eingereichtet und selbst ein Ergänzen der originalen AVM-Oberfläche um eine passende Anzeige zum Status so einer OpenVPN-Verbindung ist (relativ) schnell gemacht. Da ist Freetz dann meiner Meinung nach eine Kanone, mit der auf Spatzen geschossen wird ... man braucht eigentlich nur das OpenVPN-Binary mit ein paar Skripten auf dem NAND-Flash und eine Möglichkeit, wieder eigene Kommandos auszuführen (seit die debug.cfg entsorgt wurde), solange der Kernel mit TUN/TAP-Support (TUN=y) übersetzt wurde. Ob man dann ein statisches OpenVPN nimmt oder auf die vorhandenen Libs zurückgreift, ist dann nur noch eine Platzfrage.
Dafür ist aber ein komplettes Freetz absoluter Overkill ... von den Implikationen aus der Verwendung von Freetz ganz zu schweigen. Wenn man das OpenVPN irgendwie updaten will, tauscht man einfach nur das Binary auf dem NAND-Flash aus und startet die Box neu.
Alles andere, was da das Freetz noch kann (von Remove-Patches bis zum eigenen CGI) wird doch gar nicht gebraucht, wenn die Box nur als OpenVPN-Client (oder sogar als Server) herhalten soll. Bei mir wird sogar das - über das AVM-GUI importierte - Zertifikat der FRITZ!Box für die Authentifizierung als OpenVPN-Client genutzt ... das muß man ja nicht alles immer noch einmal neu erfinden (also die Zertifikatverwaltung der Box) oder doppelt vorhalten (mit einem zweiten Zertifikat).
