Beschreibbares Dateisystem bei usbroot problematisch?

[WEARENOTALONE]

Guten Abend,
seit Freitag migriere ich meine Fritzbox 7170 auf Freetz 1.0 ( Aktuell ist r2368 ). Da Freetz mit der AVM Firmware 29.04.57 ziemlich viel Platz benötigt, habe ich das Paket usbroot 0.1 ausprobiert. Dabei ist mir folgendes aufgefallen:

Das Skript /etc/init.d/rc.usbroot bindet den USB Stick beschreibbar ein. Wenn die Fritzbox aber z.B. aufgrund eines Stromausfalls neu bootet, wird das Dateisystem nicht richtig ausgehängt. Wenn man an dem Dateisystem Änderungen vorgenommen hat, ist eventuell nach einen solchen Neustart derart beschädigt, dass die Fritzbox garnicht mehr bootet. Das Problem ist bei mir aufgetreten (Netzstecker gezogen) und ich musste erst den USB Stick abziehen um die Box booten zu können.

Um das Problem zu umgehen, remounte ich den USB Stick nun am Ende des Bootvorgangs in der rc.custom nur lesbar mit:

mount -o remount,ro /

Nun frag ich mich allerdings:
1. Ist dies ausreichend?
2. Gibt es irgendwelche Programme die bei der Verwendung von usbroot Schreibrechte auf den USBStick benötigen (=> event. neue Probleme)?
3. Kann man den USBStick schon direkt im usbroot Skript nur lesbar mounten? Ein kleines "-o ro" hinter dem Mountbefehl in Zeile 79 hat nicht leider nicht funktioniert, kA warum.

Auf den ersten Blick gefällt mir Freetz übrigens sehr gut, mal schaun wie sich Freetz im Langzeittest gibt.

Mit freundlichen Grüßen
WANA

 

[derheimi]

Hallo,

den USB-Stick nur lesbar zu mounten, sollte das Problem erstmal beseitigen. Allerdings reicht es nicht aus, wenn du das File auf dem Stick änderst, sondern Du musst das geflashte File verändern - das war vermutlich die Ursache, warum es bei Dir nicht funktioniert hatte. Es sollte keine Probleme geben, wenn Du das nur RO mountest, da der Stick für Freetz nur wie ein vergrößterter Flashspeicher verwendet wird und darin eigentlich nicht geschrieben wird - das ist nur für Entwickler einfacher, wenn man einfach mal was probieren will und nicht ständig neu flashen mag.

Eine Alternative wäre es ev., wenn man statt ext2 ein ext3 verwendet und dann mit der Option "-o sync" mountet. Aber das habe ich selbst mangel Zeit noch nicht ausprobiert.

 

[olistudent]

Ich hatte ja ext2 genommen, weil das ext2 Modul in der Firmware vorhanden ist. Und so auch funktioniert, wenn unsere Kernelsourcen veraltet sind.
Aber die Idee mit dem Journal finde ich trotzdem gut.

MfG Oliver

 

[poruid]

Eine Alternative wäre es ev., wenn man statt ext2 ein ext3 verwendet und dann mit der Option "-o sync" mountet. Aber das habe ich selbst mangel Zeit noch nicht ausprobiert.

Shouldn't it be either ext2 with mount option sync or ext3; with ext3 (journaled) usage of the sync option is not required to keep the file system in a consistent state. Besides, use of the sync option on a flash based device (e.g. a USB memory key) might, due to the ware caused by the many writes to the device, degrade the memory key quickly.

BTW. The problem is caused by the filesystem not being properly unmounted when the FB is rebooted or halted The hotplug replacement being developed by jonhbock would remedy this shortcoming.

 

[WEARENOTALONE]

Vielen Dank für die Tipps!

Wie mir anhand eurer Antworten aufgefallen ist, hab ich euch leider einige Informationen versehentlich vorenthalten:

Um den USB Stick nur lesbar zu mounten, habe ich das rc.usbroot Skript in Zeile 79 mit "-o ro" erweitert und in das Freetz Image integriert. Außerdem habe ich einen neuen Ordner mit dem Namen oldroot im Image erstellt, um nicht in Konflikt mit Zeile 232 ("[ -d $OLDROOT ] || mkdir -p $OLDROOT") zu kommen. Nach dem Einspielen des neuen Images, hab ich usbroot aktiviert und die Box neugestartet. Allerdings wird, aus mir unbekannten Gründen usbroot nach dem Neustart nicht aktiviert. Meine Vermutung ist, dass Zeile 234 ("if pivot_root . $OLDROOT; then") nicht mit einem Readonly Dateisystem funktioniert.

Wenn ich rc.usbroot unverändert lasse, wird der USB Stick normal eingebunden. Grundsätzlich ist usbroot also funktionstüchtig.

Um das Problem mit dem inkonsistenten Dateisystem zu umgehen, remounte ich zum Einen den USB Stick in der rc.custom Readonly, zum Anderen verwende ich das ext3 Dateisystem. ext3 setze ich ein, da im Zeitfenster vom Mounten des USB Sticks bis zum Readonly Remounten der Stick beschreibbar ist und es so zu Problemen (z.B. Stromausfall) kommen könnte. Aufgrund des Journals sollten diese Fehler aber leicht von der Fritzbox selbst behebbar sein. Das Problem, dass die Fritzbox nach einen Stromausfall garnicht mehr bootet (z.B. bei ext2, beschrieben im ersten Beitrag), sollte somit nicht mehr auftreten.

ext2 in Kombination mit dem sync Flag verwende ich nicht, weil ich unter anderem hier (equivalent zu poruid's Anmerkung) gelesen hab, dass sync die Lebenszeit eines USB Sticks drastisch verkürzen kann.

Am Liebsten wäre mir eigentlich, wenn ich den USBStick gefahrlos beschreibbar einbinden kann. Dann kann ich unter anderem eine Swap Datei auf dem USB Stick anlegen. Allerdings bin ich mir nicht sicher, ob ext3 wirklich so perfekt ist, dass das Dateisystem selbst nach einem Stromausfall noch konsistent ist. Leider kommen Stromausfälle bei uns in letzter Zeit häufiger vor. Ich kann meiner Familie aber nicht zumuten, dass nach einem Neustart die Box wegen einem fehlerhaften Dateisystems nicht hochfährt und nur weil ich gerade nicht zuhause bin, das Telefonieren mehrere Stunden nicht möglich ist. Ich hoffe, dass es eine Lösung für das Problem gibt, bei der ich trotzdem weiterhin den USBStick, eventuell sogar beschreibbar, verwenden kann.

BTW. The problem is caused by the filesystem not being properly unmounted when the FB is rebooted or halted The hotplug replacement being developed by jonhbock would remedy this shortcoming.

Beim Herunterfahren der Box könnte der hotplug Ersatz von johnbock helfen, aber nicht bei einem Stromausfall.

Kurz zusammengefasst, stellen sich mir (bzw. ich euch ) nun folgende Fragen:
1. Sind meine Vorkehrungen mit Readonly-Mounten in rc.custom und Verwenden von ext3 ausreichend, um für einen Stromausfall gewappnet zu sein?
2. Beantwortet durch derheimi: In das usbroot Dateisystem wird vom System aus nicht geschrieben, dient nur den Entwicklern.
3. Woran kann es liegen, dass ein "-o ro" in Zeile 79 in /etc/init.d/rc.usbroot nicht funktioniert? Oder funkionierts bei jemandem?
4. Gibt es vielleicht doch eine Möglichkeit den USB Stick gefahrlos beschreibbar zu mounten? Ist ext3 dafür vielleicht schon ausreichend?

Mit freundlichen Grüßen
WANA

 

[derheimi]

Der Link zum sync-Flag ist sehr interessant. Aber ich würde bei ext3 auch vorsichtig sein: wird da nicht spätestens alle 5 Sekunden ein Journal-Log geschrieben? Das wirkt sich doch auch sehr negativ auf die Lebensdauer aus?

Das mit dem -o ro würde ich glatt mal selbst ausprobieren. Ich komme aber erst am Wochenende dazu.

Es wäre vielleicht am besten, ein spezielles Flashfilesystem für den USB-Stick zu verwenden. Aber wenn ich mich recht erinnere, kann man das nicht so einfach auf "traditionelle" Blockdevices legen.

 

[McNetic]

Naja, ich glaube, letztendlich ist der Punkt 'geringe Lebensdauer' bei Flash-Speichern (insbesondere bei den neuen) nicht mehr so ein großes Problem. Das wurde schon häufiger mal hier im Forum geschrieben. Die C't hat vor längerer Zeit einen großen Test gemacht, um die Lebensdauer von Flash-Speichern zu testen, und es ist ihnen nicht gelungen, einen 'kaputt' zu schreiben.

 

[johnbock]

Der Link zum sync-Flag ist sehr interessant. Aber ich würde bei ext3 auch vorsichtig sein: wird da nicht spätestens alle 5 Sekunden ein Journal-Log geschrieben? Das wirkt sich doch auch sehr negativ auf die Lebensdauer aus?

Yes, you're right. Using sync has the same problems though. You could use a key with a higher guarantied number of write cycles: I've seen up to a million, most have 100k. There are also ultra mini 1.8" HD's on the market or a 2.5" with an active hub.

 

[WEARENOTALONE]

Das mit dem -o ro würde ich glatt mal selbst ausprobieren. Ich komme aber erst am Wochenende dazu.

Das wäre gut, vielleicht habe ich etwas übersehen.

Aber ich würde bei ext3 auch vorsichtig sein: wird da nicht spätestens alle 5 Sekunden ein Journal-Log geschrieben? Das wirkt sich doch auch sehr negativ auf die Lebensdauer aus?

In der Voreinstellung wird alle 5 Sekunden das Journal geschrieben. Mit der Mountoption "commit=Anzahl der Sekunden" kann man diesen Wert verändern. Außerdem ist mir noch ein ganz anderes Problem aufgefallen. Standardmäßig wird beim Mounten die Option atime mit angegeben (verbirgt sich hinter defaults). Diese kleine Option sorgt dafür, dass bei jedem Lesen der Datei die Zugriffszeit (accesstime) geändert (geschrieben) wird. Dies geht unter Umständen zu Lasten der Performance und Lebensdauer. Unter anderem Linus Torvalds und Ubuntu verwenden deshalb noatime+noadirtime als Mountoptionen, siehe hier. Auf meinem Rechner werden alle Partitionen mit relatime eingebunden, so dass sich atime nur bei Änderungen von ctime und mtime ändert. Diese Option gibts aber wohl erst ab Kernel 2.6.20, also nicht auf der Fritzbox, siehe hier.

Wie McNetic geschrieben hat, scheint die Lebensdauer von USB-Sticks heute allerdings kein großes Problem mehr zu sein. Prinzipiell sind USB-Sticks in ihrer Lebensdauer begrenzt, allerdings zögert ein gutes Defektmanagement (z.B. mit Wear-Leveling-Algorithmen) das Ende heraus:

Quelle: c't 23/2006
Wie effizient das Defektmanagement und die Verteilung der Daten funktioniert, zeigt ein Versuch im c't-Labor: Wir haben probiert, einen USB-Stick mit Flash-Speicher gezielt kaputt zu schreiben. Aber selbst nach 16 Millionen Schreibzugriffen auf ein und dieselbe Datei konnten wir keine Fehler feststellen.

Falls sich jemand dafür näher interessiert, findet er bei Wikipedia viele Informationen zu Flash-Speichern.

Den Vorschlag von derheimi mit dem speziellen Flashdateisystemen find ich wirklich gut. Spontan fällt mir da JFFS2 ein, dass auch von Freetz als Modul mitgeliefert wird. Allerdings hab ich damit wenig Erfahrung bzgl. der Probleme mit "traditionellen" Blockdevices. Was genau meinst du damit? Wo liegen die Probleme?

Unabhängig davon wäre es praktisch, wenn man die Mountoptionen ebenfalls bei dem rc.usbroot Skript angeben kann. Mein Vorschlag wäre die Mountoptionen optional einfach hinter dem Pfad angeben zu können, zum Beispiel so:

rc.usbroot store /dev/sda1:/usbroot ro,relatime

Die Optionen könnte man genauso wie den Pfad in /proc/sys/urlader/environment (kernel_args1) speichern. Ich werde versuchen die rc.usbroot dementsprechend anzupassen aber gebt mir ein wenig Zeit

Falls jemand die Fragen aus meinem letzten Beitrag aufgreifen möchte, hät ich nichts dagegen Speziell die Frage, wie man ein Dateisystem zuverlässig beschreibbar einbinden kann, interessiert mich brennend. Reicht die Mountoption sync wirklich aus um das Dateisystem auch im Falle eines plötzlichen Neustarts konsistent zu halten?

Gruß,
WANA

 

[WEARENOTALONE]

Nach erfolgreichem Testen habe ich euch im Anhang einen Patch für rc.usbroot hochgeladen. Der Patch erlaubt nun die Angabe von Mountoptionen hinter dem USB Pfad. Ein Beispiel wäre:

rc.usbroot store /dev/sda1:/usbroot ro,sync

Das Skript kann aber auch weiterhin ohne Mountoptionen aufgerufen werden, zum Beispiel so:

rc.usbroot store /dev/sda1:/usbroot

Der zweite Patch sorgt dafür, dass beim Systemstart über rc.usbroot statt des ext2 Moduls das ext3 Modul geladen wird. Somit wird der USB Stick als ext3 Dateisystem eingebunden.

Um die Patches anzuwenden, müsst ihr die Patches zuerst in das freetz-Verzeichnis entpacken. Danach werden die Änderungen mit

cat rc.usbroot-mit-mountoptions.patch | patch -p0
cat rc.usbroot-mit-ext3.patch | patch -p0

übernommen. Mit einem --dry-run (z.B. cat rc.usbroot-mit-mountoptions.patch | patch -p0 --dry-run ) am Ende kann man erstmal überprüfen, ob die Patches überhaupt passen. Jetzt könnt ihr mit dem Befehl make ein neues Image erstellen. Eventuell ist vorher ein make clean notwendig (oder ihr kopiert einfach die gepatchte rc.usbroot nach packages/usbroot-0.1/root/etc/init.d )

Wenn ihr die Mountoption ro für readonly benutzen wollt, muss zuerst auf dem USB Stick ein Verzeichnis oldroot erstellt werden. Ich benutze momentan die Mountoptionen ro und sync. Das Problem, dass beim Setzen der Mountoption ro der USBStick nicht mehr eingebunden wird (siehe ersten Beitrag) konnte ich nicht mehr reproduzieren. Das einzige Problem das ich noch nicht lösen konnte ist, dass das "alte" Dateisystem der Fritzbox nicht im Verzeichnis /oldroot gemountet wird, obwohl es auf dem Stick existiert. Habt ihr Vermutungen woran das liegen könnte?

Mit freundlichen Grüßen
WANA

 

[olistudent]

Eventuell ist vorher ein make clean notwendig (oder ihr kopiert einfach die gepatchte rc.usbroot nach packages/usbroot-0.1/root/etc/init.d )

make usbroot-dirclean

sollte ausreichen.

Beim pivot-root wird das alte Dateisystem ja irgendwohin geschoben. Wenn es unter oldroot nicht mehr da ist, dann wird es im Script "unmounted".

MfG Oliver

 

[McNetic]

Ich wäre dafür, das in Freetz aufzunehmen. Es wäre super, wenn Du ein Ticket dafür aufmachen und die Patches ungezippt dort anhängen könntest, dann schaue ich mir das auch mal genauer an.

 

[WEARENOTALONE]

Die Patches sind nun ungezippt unter dem Ticket 209 im Trac zu finden.

Ist es eigentlich möglich dem urlader (?!?) unter /proc/sys/urlader/environment weitere Variablen zu übergeben? Meine Idee ist es, mithilfe einer weiteren optionalen Variable (z.B. kernel_args2) dem Benutzer zu erlauben, den Dateisystemtyp oder das Kernelmodul für das Dateisystem angeben zu lassen. Momentan muss man Freetz jedes Mal neu flashen, wenn man das Dateisystem auf dem USB Stick wechseln will. Leider reicht beispielsweise ein einfaches echo "kernel_args2 ext3" > /proc/sys/urlader/environment nicht aus, um eine weitere Variable zu speichern.

Gruß,
WEARENOTALONE

 

[olistudent]

Du kannst nur die schon "vorbelegten" Variablen nutzen. Diese sind irgendwo (bin grad zu faul zum suchen) in den Kernelsourcen zu finden...

MfG Oliver

 

[WEARENOTALONE]

Wer sucht, der findet hier und hier...

In den Kernel-Sourcen habe ich bisher noch nichts über die Kernelargumente gefunden. Außerdem finde ich nur Informationen über die Variable kernel_args, aber leider nichts über die Variable kernel_args1.

 

[derheimi]

Ich bin so frei und hol das Thema nochmal hoch.

In den Kernel-Sourcen habe ich bisher noch nichts über die Kernelargumente gefunden.

Man kann dem Kernel "command line arguments" (damit eine Suchmaschine Deiner Wahl füttern mitgeben. Ich vermute, dass die von AVM's EVA einfach in zwei (Teil-)Zeichenketten verwaltet werden - warum auch immer.

Ich habe die USB-Root-Geschichte mal ein bisschen überarbeitet. Unter anderem gibts jetzt ein WebInterface und die Geschichte mit dem wählbaren Dateisystem sollte gehen. Dazu einfach mal Rev. 2395 oder höher auschecken und testen.

 

[RalfFriedl]

Ich vermute, dass die von AVM's EVA einfach in zwei (Teil-)Zeichenketten verwaltet werden - warum auch immer.

Weil die Länge eines Eintrags begrenzt ist.

 

[poruid]

Ich habe die USB-Root-Geschichte mal ein bisschen überarbeitet. Unter anderem gibts jetzt ein WebInterface und die Geschichte mit dem wählbaren Dateisystem sollte gehen. Dazu einfach mal Rev. 2395 oder höher auschecken und testen.

Very nice, a few remarks though:
- Should this change not be added to ticket# 209?
- The code assumes and hardcodes hotplug to /sbin/hotplug. This makes USB-root incompatible with the hotplug replacement based on mdev that is being developed by johnbock. Saving the value of /proc/sys/kernel/hotplug for restoral when re-enabling hotplug could help.
- Most *-root packages have a lot in common, they differ in the device used to acommodate the root FS. Should these packages not leverage a common set of functions?

 

[derheimi]

- Should this change not be added to ticket# 209?

ACK, but I'm a "trac beginner". How to add this afterwards?

- The code assumes and hardcodes hotplug to /sbin/hotplug. This makes USB-root incompatible with the hotplug replacement based on mdev that is being developed by johnbock. Saving the value of /proc/sys/kernel/hotplug for restoral when re-enabling hotplug could help.

I didn't studied johnbock's patch yet so I don't know if the hotplug replacement is already active when rc.usbroot runs. I guess at this moment the kernels default "/sbin/hotplug" is still in place. However, you are right: good code should save and restore the value, fixed in r2397.

- Most *-root packages have a lot in common, they differ in the device used to acommodate the root FS. Should these packages not leverage a common set of functions?

Ack. Volunteers? ;-)