USBROOT mit EXT4

Soll ich ein Ticket für den Patch erstellen?


  • Anzahl der Umfrageteilnehmer
    3
  • Umfrage geschlossen .

torsknod

Neuer User
Mitglied seit
14 Jun 2008
Beiträge
4
Punkte für Reaktionen
0
Punkte
0
Hallo,
ich benutze seit einigen Wochen dank einem Patch USBROOT mit EXT4 auf meiner 7390.
Den Patch würde ich gerne zu freetz beisteuern.
Wenn ich das richtig verstehe, soll man aber erst hier im Forum nachfragen, bevor man ein Ticket eröffnet. Das tue ich hiermit. Da die Anhangs-Funktion nicht zu funktionieren scheint (Fenster öffnet sich, bleibt aber leer), habe ich ihn hier eingefügt:

Code:
[FONT=monospace][COLOR=#000000]From b139cce1e5f26a556eac5a8ca52381bf86d9b118 Mon Sep 17 00:00:00 2001[/COLOR]
From: Torsten Knodt <[email protected]>
Date: Sun, 23 Oct 2016 14:50:48 +0200
Subject: [PATCH] Support EXT4 for USBROOT

---
 make/usbroot/files/root/etc/init.d/rc.usbroot | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/make/usbroot/files/root/etc/init.d/rc.usbroot b/make/usbroot/files/root/etc/init.d/rc.usbroot
index e425009..4699dda 100755
--- a/make/usbroot/files/root/etc/init.d/rc.usbroot
+++ b/make/usbroot/files/root/etc/init.d/rc.usbroot
@@ -454,7 +454,7 @@ cleanup_on_failure() {
 get_fstype() {
        # check if kernel modules are available
        # or if filesystem support is already built-in and available
-       for i in ext2 ext3; do
+       for i in ext2 ext3 ext4; do
                if [ -f "/lib/modules/$(uname -r)/kernel/fs/$i/$i.ko" ]; then
                        eval $i=y
                elif [ -n "$(grep $i /proc/filesystems)" ]; then
@@ -470,13 +470,17 @@ get_fstype() {
        fi
  
        # result matrix (only handle some special cases, thread all other cases as ext2)
-       case "$ext2:$ext3:$mediafs" in
-               n:y:*)
+       case "$ext2:$ext3:$ext4:$mediafs" in
+               n:n:y:*)
+                       FSTYPE="ext4" ;;                # only ext4 available
+               n:y:n:*)
                        FSTYPE="ext3" ;;                # only ext3 available
-               y:y:*)
-                       FSTYPE=${mediafs:-ext2} ;;      # use fs type from media or ext2 as default
+               y:n:n:*)
+                       FSTYPE="ext2" ;;                # only ext2 available
+               y:y:*:*|y:*:y:*|*:y:y:*)
+                       FSTYPE=${mediafs:-ext4} ;;      # use fs type from media or ext4 as default
                *)
-                       FSTYPE="ext2" ;;                # defaults to ext2
+                       FSTYPE="ext4" ;;                # defaults to ext4
        esac
  
        # user can force a fs type if kernel module is available
--  
2.7.4[/FONT]

Gruß
Torsten
 
Hallo Torsten,
welche Problemstellung fixt dieser Patch ?
oder welches neue Feature bringt dieser Patch für Anwender ?

Hilft dies evtl. für Problemstellung http://www.ip-phone-forum.de/showthread.php?t=288246

ansonsten hast Du meine Unterstützung.

Gruß
Pokemon20021
 
Wo läge für das Root-Filesystem einer FRITZ!Box denn der Vorteil, wenn man "ext4" anstelle von "ext3" (das ja auch schon "journaling" erlaubt) verwendet?
 
Der Fix ist, dass ext2 und ext3 unterstützt werden, das inzwischen vorhandene ext4 aber nicht.

Für mich als Anwender war der Hauptgrund für den Patch, dass ich die schon vorhandenen Dateien nicht erst umparken wollte (hätte mir eine Platte leihen müssen) um dann auf ext3 umzuformatieren.
Der Grund um den Datenträger ursprünglich als EXT4 zu formatieren war die Unterstützung für TRIM. Ich habe aber ehrlich gesagt nicht geprüft, ob der aktuelle Kernel die Unterstützung schon hat.
Wenn man keine SSD oder anderen Flash Speicher anschließt, ist eventuell die Online Defragmentierung noch interessant, besonders wenn man den Cache für den Online Speicher darüber laufen hat.
Zuletzt bietet EXT4 Prüfsummen für Metadaten. Diese ersetzen zwar kein Backup, reduzieren aber die Wahrscheinlichkeit dass korrupte Daten in das Backup geraten.

Ich hatte auch über einen Wechsel zu BTRFS nachgedacht, um zu prüfen ob die Kompression einen Geschwindigkeitsvorteil bietet. Ich weiß nicht mehr was der Grund war, warum ich das nicht getestet habe. Entweder war der Support im Kernel noch nicht vorhanden oder mir hat der Mut gefehlt.

Der Tipp mit dem anderen Thread hilft mir wenig, da alles außer USBROOT funktioniert hat. Zumindest meine ich mich daran zu erinnern. Den Patch habe ich schon vor einer Weile erstellt und wollte ihn eigentlich nur 2 Wochen testen, bevor ich ihn anbiete. Das ganze ging dann bei mir aber unter bis ich jetzt auf eine aktuelle FritzOS Version aktualisieren wollte und dabei die nicht committeten Datei wiederentdeckt habe.
 
Das "Umformatieren" wäre ja nicht notwendig, man kann eine "ext4"-Partition auch problemlos als "ext3" mounten.

Eine SSD an die FRITZ!Box anzuschließen, dürfte mit dem Vollblut-Springpferd vor dem Pflug vergleichbar sein. Auch ansonsten sollte man - sogar bei "usbroot" - eine Trennung zwischen (ständig) beschriebenen Dateisystemen und solchen, die eher einen statischen Charakter haben, vornehmen - nicht nur unter dem Aspekt, daß man ggf. bei so einer FRITZ!Box auch schon mal den Stecker ziehen muß und bei aller Unterstützung für Journaling dann ein Problem im Dateisystem auftreten kann.

Betrifft so ein Problem dann die Partition mit dem "rootfs", ist das eher ein Grund für eine nicht startende Box (abgesehen von der Fragmentierung, die gar nicht erst - in nennenswertem Umfang - für das "rootfs" auftritt, wenn man die Dateisysteme trennt, denn dort sollten praktisch keine Schreibzugriffe erfolgen) als wenn da nur eine weitere Partition für volatile Daten ein Problem hat - letztere kann man dann auch problemlos neu formatieren lassen, nachdem man noch vorhandenen Daten (z.B. Protokolle) im r/o-Modus gesichert hat. Warum man ein (regelmäßiges) Backup des "rootfs" einer FRITZ!Box machen sollte, kann ich auch nicht so richtig erkennen - vermutlich fehlt es mir da an Phantasie. Ich wollte ja nicht auf die generellen Vorteile bzw. Änderungen von "ext4" ggü. "ext3" hinaus - ich meinte schon den konkreten Einsatzfall bei einer FRITZ!Box und hier sogar den, daß es sich um das "rootfs" handelt.

Der entscheidende Nachteil bei den Neuerungen von "ext4" dürfte es wieder sein (zumindest an einer FRITZ!Box), daß alle zusätzlichen Merkmale für "ext4" (die ich ohnehin für irrelevant halte bei einer FRITZ!Box, aber das ist nur meine persönliche Einschätzung) dann auch zusätzliche I/O-Operationen nach sich ziehen und da der USB-Port in der Box ohnehin schon nicht der schnellste ist, dauern dann Zugriffe insgesamt noch länger. Das gilt auch für die Verwendung von komprimierenden Dateisystemen ... das müßten schon extrem gut zu komprimierende Daten sein, damit der zusätzliche Rechenaufwand für die (De-)Komprimierung durch Einsparung an zu übertragenden Daten einen echten Nutzen bringt. So eine FRITZ!Box hat eben keinen x86-/x64-Prozessor und bei der 7390 gibt es nicht einmal den zweiten Core ... das will also gut überlegt sein, was da am Ende tatsächlich als Effekt übrig bleibt. Beim eMMC bei der 6490 hoffe ich mal, daß AVM da getestet hat und der Effekt "ext4" vs. "ext3" zu vernachlässigen war. Auch da gilt ja wieder, daß die Absicherung über eine Prüfsumme (und i.d.R. wird NAND-Flash ja bereits mit ECC gesichert) ausreichend sein sollte - man kann es mit den Sicherungsmaßnahmen nämlich auch übertreiben (selbst wenn das verschiedene Schichten sind).

Auch die Verwendung von SquashFS durch AVM hat natürlich entsprechende "Kosten" bei der Dekomprimierung der Daten ... aber die dort verwendeten Algorithmen brauchen eben beim Komprimieren viel Zeit und Rechenleistung und beim Dekomprimieren nur noch wenig. Ansonsten würde die Platzersparnis (beim NAND-Boxen wäre noch einiges an Platz übrig, da könnte man sogar unkomprimierte Firmware verwenden, wenn man wollte) vermutlich weniger ein Argument sein, die Reduktion der notwendigen Zugriffe auf den (langsameren) Flash-Speicher dürfte das wieder ausgleichen. Bei den NOR-Boxen ist das dann noch ein wenig anders, dort steht der NOR-Speicher ja für direkten Zugriff zur Verfügung (auch wenn der sicherlich immer noch langsamer erfolgt als beim Zugriff auf RAM-Speicher).
 
Sorry, wer rrd-Datenbanken bei einer FRITZ!Box direkt auf dem USB-Speicher beschreibt und das nicht im tmpfs abfedert, der macht m.E. ohnehin etwas falsch - selbst wenn das MRTG oder etwas ähnliches sein sollte.

Der Anlaufstrom mag noch als Argument herhalten ... aber eine "SATA-6G capable" SSD in einem Case mit USB-SATA-Converter ist an einer FRITZ!Box schon ziemliche Verschwendung.

Datensicherheit hin oder her ... wenn man da alle 30 Minuten oder beim Reboot die rrd-Datenbanken auf den Stick schreibt, reduziert das die Belastung des Flashs auf dem Stick schon mal auf 1/30stel - ich weiß ja nicht, wie oft bei Dir eine FRITZ!Box "hart" gestartet werden muß, so daß sie keine Sicherung einer "rrd" aus dem "tmpfs" mehr auf den Stick bringen kann (z.B. im Rahmen der /var/post_install).

Selbst wenn man eine so große Datenbank brauchen sollte, daß die besser nicht im "tmpfs" abgelegt wird (bei rrd muß ja die Größe vorher festgelegt werden), dann ist sicherlich die regelmäßige Konsolidierung der Daten (also das Übertragen aus der DB im "tmpfs" in eine andere auf dem Stick) der bessere Ansatz.

Daß man Flash-Speicher (eigentlich nicht einmal den in einer SSD) nicht mit "normalem" verwechseln sollte, wenn es um (unnötige) Schreiboperationen geht, ist eine der "Grundweisheiten" beim Entwurf solcher Geräte. Selbst eine SSD muß sich intern mit "wear leveling" ja gegen das zu häufige Beschreiben derselben Speicherzellen wappnen und da macht es am Ende auch nur die schiere Menge an Speicherzellen, wenn die langsamer kaputt geht als ein (moderner) USB-Stick. Auch da haben die meisten Controller inzwischen entsprechende Algorithmen zur Verfügung, um die Lebenszeit des gesamten Gerätes zu vergrößern - rein beim "wear leveling" dürften die sich nur wenig unterscheiden. Den anderen, entscheidenden Vorteil der SSD (hohe Übertragungsrate durch passende Schnittstelle zum Host) kann eine SSD mit einem USB-SATA-Converter ja gerade nicht ausspielen und dann kommt noch der ziemlich lahme USB-Port bei der FRITZ!Box als "Strafe" oben drauf.
 
Das USB3 Case bremst dabei jedenfalls nicht.
Das muß dann aber eine SSD mit einem sehr, sehr langsamen "nativen" Interface sein, wenn da USB3 (erst recht bei der 7490, wo der Unterschied zu USB2 ja praktisch nicht vorhanden ist) nicht bremst.
 
Wir reden hier immer noch von der FRITZ!Box und nicht von den theoretischen, sondern von den praktisch zu erzielenden Werten an einer FRITZ!Box, oder?

Ich tue das jedenfalls und kann mich des Eindrucks nicht erwehren, daß wir aneinander vorbeischreiben.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.