FB 7270: Soft-Raid möglich?

[JoeCool25]

Hallo,
nur mal rein interessehalber ist/wäre es mit der 7270 möglich 2 USB Festplatten an einem USB-Hub in einem Soft-Raid Verbund (Raid 1) laufen zu lassen, oder reicht dafür die Hardware (CPU,RAM) der Fritzbox nicht aus?

Danke!

Mfg Oliver

 

[RalfFriedl]

Warum sollte sie nicht ausreichen? Oder meinst Du das ausreichen eher subjektiv, daß es Dir dann zu langsam wäre?

 

[Silent-Tears]

Es sollte Hardwaretechnisch ausreichen, denn "echte" Raid-Controller besitzen auch nur eine begrenzte Rechenleistung und bekommmen das hin. Vergiss dabei aber nicht, dass der USB-Bus an den AVM-Geräten nicht wirklich performant ist. Von daher ist die eigentlich Bremse dann wohl am USB-Bus zu suchen.

 

[bof]

Ich habe RAID1 an einer 7270 zum laufen bekommen. Habe zwei Samsung 640GB Platten an einem 7-Port-Hub. Fuer sich taten die sofort. Auf benachbartem Rechner habe ich auf ihnen ein RAID1-Paartitioenchen eingerichtet und mit ext2 formatiert.

Erste Überraschung beim Anstecken an Fritz: die beiden ext2-Partitionen werden jeweils separat unter /var/media/ftp/ eingehängt, ohne ihr Dasein als zwei Spiegelhaelften zu beruecksichtigen.
Schnell von Hand umounten... Das ist nicht fein.

Nächste Schritte wie zu erwarten: Freetz-Kernel mit md+raid1-Support backen, /dev/md0 anlegen, raidautorun, und mount - klappte. dd-Lesen laeuft mit etwa 13 MB/s, schreiben mit 9 MB/s.

Habe mir mittlerweile mdadm portiert. Damit kann man unter anderem pruefen, ob eine Partition als md-device formatiert ist. Das habe ich in /etc/init.d/run_mount reingepatcht, direkt vor dem zu vermeidenden "if do_umount".

Als nächstes will ich ein rc.mdadm stricken, das die Assembly der Spiegel automatisiert, und ein cgi dazu. Kann aber etwas dauern, ich spiele erst seit ein paar Tagen mit Freetz und der Box...

 

[bof]

md RAID support

Anbei das Ergebnis meiner bisherigen Basteleien bezüglich md-Support. Ich arbeite mit freetz-1.1.1, die tarfiles sollten dort im Hauptverzeichnis entpackt werden. Es braucht dann noch folgende Zeilen zusätzlich in make/Config.in, damit "make menuconfig" (bei mir unter Testing) die drei Pakete baut:

source make/mdadm/Config.in
source make/mdavoid/Config.in
source make/mdstart/Config.in

(es lohnt sich, dann bei "make menuconfig" mit "?" in die Hilfstexte zu schauen.)

mdadm und mdavoid würde ich "erst mal fertig" nennen, mal davon abgesehen, dass ich mdavoid nur fuer 7270_v3 wirklich patchen lasse, weil das an's offene Herz geht und ich andere Boxen weder kenne noch testen kann.

mdstart ist sicher nicht fertig. Kann man auch weglassen. Ich weiss selbst noch nicht so genau, was ich da will, und muss mich dringend noch genauer mit dem hotplug-Pfad und einem sauberen shutdown befassen... Das angehängte Paket reicht, um beim booten angeschlossene und in /etc/mdadm.conf festgelegte Arrays automatisch zu starten. mdstart bringt auch ein CGI mit, zur Statusanzeige, und einen Viewer/Editor für /etc/mdadm.conf, der bei entsprechendem Security-Level auch Schreiben zulässt.

Hoffe, das war/ist für irgendjemanden interessant. Bin insbesondere auch gespannt auf Hinweise, wo ich das Freetz-Bauen noch nicht richtig verstanden habe.

Ganz allgemein will ich ausserdem mal dick Danke sagen - bin schwer beeindruckt von der Qualität der Box selbst, und speziell auch von Freetz.

liebe Gruesse
Patrick

 

[Silent-Tears]

Hmm, Entwicklungne laufen normalerweise gegen dne Trunk ab. Kannst du vllt.. mal shauen, dass ud das auch in dieser Richtung forcierst? Danke.

 

[bof]

Hmm, Entwicklungne laufen normalerweise gegen dne Trunk ab. Kannst du vllt.. mal shauen, dass ud das auch in dieser Richtung forcierst? Danke.

Werde ich sicher machen. Zum Kennenlernen hatte ich mich halt für die aktuellste "stable" entschieden.

Hat sich am make/build zum trunk hin viel geändert?

 

[Silent-Tears]

Inzwischen sind dort mehrere Monate Diskrepanz. Es wird sich einiges geändert haben, bedarf aber nur "kleinerer" Anpassungen. Demnächst wird es noch einmal ne gössere Änderung geben.
Du könntest also:

a) warten und mehr anpassen
b) das jetzt machen und hoffen, dass die Devs das miterledigen

Ich mag noch dazusagen, dass wir nichts gegen den stable-branch an Neuerungen einchecken werden, dort kommen nur Bugfixes und Versionssprünge der zugrundeliegenden Firmwareversionen hin.

Da es ausserdem langsam aber sicher auf einen Feature-Freeze zugeht, solltest du auch in Richtung trunk arbeiten, denn osnst kommt es erst danach in den trunk, und somit auch erst in eine potentielle übernächste Version.

 

[bof]

Danke für die Orientierung. Dass das in ein stable reingeht, hätte ich auch nicht erwartet

Bin dabei, trunk zu bauen. Den menuconfig-Teil aus meinen .tar.gz's musste ich schonmal nicht anfassen. Jetzt baut sich der Kram erst einmal, und dann schaue ich mal ob er läuft oder ob ich lerne wie man recovery macht...

Spass!

 

[bof]

Habe trunk problemlos zum Laufen bekommen.

An meinen drei .tar.gz's musste ich nichts ändern, sie können also auch auf den trunk gepackt werden, falls gewünscht.

Sollte ich das nochmal in anderer Form (svn xxx-mach-es-so?) zusammenstellen? Bin Arbeiten mit svn nicht gewohnt, und das trac-wiki hört in etwa da mit Erklären auf...

 

[Silent-Tears]

Jups. ein PAtch wäre cool, und: svn howtos gibts wie sand am meer Nicht existierende Dateien/Verzeichnisse mit "svn add" hinzufügen, und dann per "svn diff" einen Patch erzeugen.

 

[bof]

[Edit frank_m24: Mehrere Beiträge zusammengefasst. Man kann seine Beiträge auch editieren.]
Nun denn, ein Patch. Habe alle drei Dinger zusammengepackt.

[Beitrag 2:]
Mal ein aktueller Datenpunkt zur Performance. Lasse gerade ein 300GB grosses Spiegelset erstmals resyncen.

Erzeugt habe ich den Spiegel von der Fritzbox aus, und habe ihm ein paar Minuten beim resync zugesehen. Das läuft mit etwa 13 MB/s.

Habe dann 'mdadm --stop' das Array an der Fritzbox rausgekegelt, die Platten an meinen Desktop gehängt, und dort das Array importiert. Der resync lief sauber an der Stelle weiter, wo er war. Mit ca. 16.5 MB/s.

Jetzt ist der Spiegel wieder an die Fritzbox zurückgewandert, und ich lasse ihn dort fertig resyncen. Der Speed bleibt bei 13 MB/s. top suggeriert mir dabei, es wären noch 30-50% idle cycles übrig. Es bleiben stabil 13 MB RAM frei. Das Webinterface fühlt sich leicht holprig an. Telefonieren scheint einfach weiter zu funktionieren.

[mke2fs/e2fsck]

Nun habe ich ein 300GB großes ext2 an der Box. mke2fs lief ca. 11 Minuten, ein e2fsck -f auf die leere Partition etwa 15 Minuten. Jeweils mit 100% cpu usage, das Webinterface wird dadurch doch sehr langsam, Testtelefonate dagegen funktionierten symptomfrei. Der e2fsck nimmt sich 28 MB RAM (virtual), ich schätze, bei einer nochmal doppelt so großen Partition würde es ziemlich knapp.

Wie schnell ist das dann in der Benutzung? Die 8 GB - Spiegelpartition, mit der ich schon die letzten Tage gearbeitet hatte, auf den gleichen Platten, hat 2 1/2 GB Platz belegt, in etwa 120000 Dateien. Die habe ich mit tar cf | tar xf auf die neue Partition kopiert. Dauerte etwas über 15 Minuten - 2 1/2 MB/s. Ein "find" durch die 120000 Dateien braucht 80 Sekunden. Und immer noch funktioniert der Telefonteil einwandfrei.

An der Stelle möchte ich etwas zur Sinnfälligkeit solch großer Partitionen sagen. Mir geht es um etwas ausfallgesicherte Storage für Fotos und Filmchen, die zB die Kinder zunehmend anfangen zu produzieren. Da kommt schnell mal eine Menge Daten zusammen, die dann nur ganz sporadisch mal wieder angeschaut werden. Bisher habe ich das auf meinen Desktop gepackt, aber da lasse ich den Rest der Familie nicht autonom ran, suche also nach einer Standalone-Lösung - so bin ich zur Fritzbox gekommen.

Die e2fsck-Zeiten bei einem solchen Setup muß man natürlich im Auge behalten. Ich denke, ich werde mir eine moderat große Systempartition machen, sagen wir mal 4 GB, und nur die beim Boot forciert checken. Die Datenpartitionen nenne ich "best effort" und mounte sie erst, wenn sie gecheckt sind, was eine nach der anderen im Hintergrund und vielleicht noch zusätzlich ausgebremst passieren kann. Ist eine Partition dann sauber, wird sie gemountet und ggf. nach /var/media/flash bind-mounted.

Kann freetzmount das? Werde ich mir als nächstes anschauen...

 

[olistudent]

Hi.
Das Paket gefällt mir bis auf ein paar Kleinigkeiten sehr gut.

Kann man nur mit mdadm erkennen, ob das md-Raids sind? Gibts vielleicht auch einen Weg ohne mdadm, dann könnten wir die neue run-mount Geschichte von hermann dahin gehend erweitern.

MfG Oliver

 

[hermann72pb]

Ich bin auch dafür, es in mein FREETZMOUNT zu integrieren. Dann brauchst du nicht rumzupatchen. Zwar kenne ich mich nicht mit mdadm aus, aber vielleicht ist es doch nicht schlimm, wenn die Zeile dort so fest steht?
Außerdem habe ich die 197-patch-Nr bereits für FREETZMOUNT genommen. Ist zwar nicht schlimm, nur so, als Anmerkung. Aber wenn es in FREETZMOUNT eingebaut wäre, dann hättest du den patch auch nicht gebraucht.

Ist die Begrenzung auf 7270 wirklich notwendig, oder nur daraus entstanden, dass du dich durch diese Tausende Box-spezifische usbstorage- und wie die alle heißen Patches wie ich nicht durchkämpfen wolltest?

Ansonsten: Daumen hoch! Tolle Arbeit! (obwohl ich persönlich dafür bei mir momentan keine Verwendung sehe, ist aber rein subjektiv und wahrscheinlich nur bei mir so)

MfG

 

[olistudent]

Bei unseren 2 Kernelversionen könnten natürlich Unterschiede auftreten. Aber zwischen den Boxen kann ich mir das nicht vorstellen.

MfG Oliver

 

[bof]

Kann man nur mit mdadm erkennen, ob das md-Raids sind? Gibts vielleicht auch einen Weg ohne mdadm, dann könnten wir die neue run-mount Geschichte von hermann dahin gehend erweitern.

Gute Idee. mdadm ist alleine zum mount-vermeiden auch zu fett. Das (mir bis gerade unbekannte) blkid
aus den e2fsprogs funktioniert. Patch müsste so aussehen - ich gehe jetzt aber erst mal ins Bett.

--- etc/hotplug/run_mount.orig
+++ etc/hotplug/run_mount
@@ -190,6 +190,8 @@
 ## mounting partition(s):
 for PART in $DEVPATH/$SDEV*; do
 BLKDEV=/dev/${PART##$DEVPATH/}
+blkid=`blkid -s TYPE $1`
+[ -n "$blkid" ] && set $blkid && [ "$2" = 'TYPE="mdraid"' ] && continue
 if do_mount $UDEV $BLKDEV ${BLKDEV##/dev/sd[a-z]} ; then
 ## no more eventadd in case of failure detection
 FAIL_EVENT=no

 

[olistudent]

Das ist gut. hermann nutzt auch blkid zur Partitionserkennung.

MfG Oliver

 

[hermann72pb]

@Oliver: War das nicht wieder diese fast rhetorische Frage/Behauptung von mir vor ein Paar Tagen, warum fstyp eigentlich unnütz ist Denn blkid wird an der Stelle eigentlich gerade dafür "missbraucht". Vielleicht sollen wir es generell auf blkid umsteigen und fstyp komplett rausschmeißen? Denn die einzig mir bis jetzt bekannte Verwendung für fstyp war in unserer mount_fs() ? Oder sehe ich es falsch?

MfG

 

[olistudent]

Wenn die Erkennung mit blkid funktioniert, dann können wir das gerne statt fstyp aufnehmen. Eine weitere Idee wäre die Utils der busybox zu nutzen. Wobei ich die busybox dann gerne erst mal auf 1.15.2 "bumpen" würde. Das wird aber eine größere Geschichte und ich komme seit Wochen nicht dazu.

MfG Oliver

 

[bof]

Der Ausgewogenheit halber muss ich leider von Rückschlägen mit meinem Raid-Setup berichten. Nachdem ich gestern mit Filesystem-Machen soweit fertig war, fing ich an, das Filesystem auch mal von extern mit ein paar mehr Daten zu füllen. Im ersten Versuch exportiert über NFS, beim zweiten Mal über ssh-in-die-box-und-untar.

Das ging jeweils einige Zeit gut, NFS mit ca. 4 MB/s, ssh/untar mit 1 MB/s. Aber leider ist beide Male irgendwann die Box komplett netzseitig verstorben - kein ping oder sonstwas ging noch. Die Telefone taten aber noch.

Die Platten selbst und ihr Hub sind in Ordnung, an meinem Desktop konnte ich das Kopieren problemlos zuende bringen. Ich schätze mal, dass der kernelseitige ext2-Code bei größeren Partitionen irgendwann zu viel RAM haben will für interne Strukturen. Aber das ist Kristallkugellesen.