[patch] quick 'n' dirty: e2fsck-check von platten beim mounten

[coolphoenix]

da woanders (http://www.ip-phone-forum.de/showthread.php?t=200293) schon an einer sauberen lösung gearbeitet wird, ich aber nicht auf das eine feature so lange warten wollte, habe ich einen patch (für die 7270) geschrieben, der folgendes macht (beschreibung in der config.in):

Does two things before mounting ext-partitions:

1) Wait some time, until date is initialized correctly
(this prevents checking a clean filesystem because of wrong date)
2) Run e2fsck on filesystem to correct errors if unclean

Be aware e2fsck is run with "-y" parameter, so every error will be corrected!
This will obviously slow down mounttime in case of an unclean filesystem.

Also note, filesystem will be mounted regardless of e2fsck exit-status (so even
when it can't correct the errors).

Debug-Messages are placed in syslog (if installed) with tags "E2FSCK" and "MOUNTCHECK"
( logread | grep E2FSCK, logread | grep MOUNTCHECK ).

wer also möchte, dass ext2/3-partitionen automatisch gecheckt werden, sofern sie unclean sind (also nicht korrekt umountet wurden), der kann diesen patch als übergangslösung benutzen.

ich selbst habe regelmäßig probleme mit zerstörten partitionen, nachdem die box mehrmals neugestartet ist, und hoffe diese damit in den griff zu kriegen.

getestet nur auf einer 7270 mit preview-labor.

nach patchen option im menuconfig -> patches unter der für autoend/autorun.sh auswählbar.

p.s. da es sowieso nur als übergangslösung gedacht ist, habe ich auch nicht darauf geachtet, den gleichen codestyle wie in anderen freetz-files zu benutzen.

 

[hermann72pb]

Danke für die erste Realisierung. Ich komme sowieso momentan kaum zu. Nur wäre es natürlich bequemer, wenn mount_fs() bereits ausgelagert wäre, dann hättest du nicht so viel rumpatchen müssen. Ich befürchte, dass deine Patches nur für 7270 sauber laufen werden. Bei den anderen Boxen könnte das rumpatchen der 3 mal bereits gepatchten und armen run_mount nicht klappen.
Ich würde sagen: Weiter so. Je mehr es testen, desto besser.
Einige Tipps meinerseits:
1. Man sollte die checks nicht in menuconfig aktivierbar machen, sondern vom WebIF heraus. Aber du hast Recht, wenn du sagen würdest, es gehöre in die endgültige Version. Denn ins Hauptmenü muss es nicht rein. Am besten machen wir daraus ein checker-Paket mit seiner eigenen cgi und cfg-Datei.
2. FAT-Systeme kannst du auch checken. Ich hatte vor kurzem dosfstools für FREETZ angepasst. Syntax ist dem von e2fsck sehr ähnlich. Das Ding heißt dosfsck. Wäre sinnvoll wegen TAM (Anrufbeantworter).
3. Wir sollten nach ntfs umschauen, ob dafür auch Checkprogramme gibt, die wir für FREETZ anpassen könnten.

MfG

MfG

 

[coolphoenix]

1. Man sollte die checks nicht in menuconfig aktivierbar machen, sondern vom WebIF heraus. Aber du hast Recht, wenn du sagen würdest, es gehöre in die endgültige Version. Denn ins Hauptmenü muss es nicht rein. Am besten machen wir daraus ein checker-Paket mit seiner eigenen cgi und cfg-Datei.

sowas wäre natürlich nett, nur noch ein webiface zu modifizieren oder zu entwerfen war mir für die schnelle aktion zu aufwändig aber prinzipiell kann es in einer finalen version die möglichkeit geben, dies zu deaktivieren.

also man muss den patch auswählen (damit alle nötigen abhängigkeiten wie e2fsck installiert werden), aber auch die möglichkeit haben, die checks im iface zu deaktivieren. (wobei ich mich frage wozu).

3. Wir sollten nach ntfs umschauen, ob dafür auch Checkprogramme gibt, die wir für FREETZ anpassen könnten.

gibt es für linux soweit ich weiß nicht

Nur wäre es natürlich bequemer, wenn mount_fs() bereits ausgelagert wäre, dann hättest du nicht so viel rumpatchen müssen. Ich befürchte, dass deine Patches nur für 7270 sauber laufen werden. Bei den anderen Boxen könnte das rumpatchen der 3 mal bereits gepatchten und armen run_mount nicht klappen.

ja, wohl wahr, aber darum kümmerst du dich doch... oder? (also auslagern der run_mount())

 

[hermann72pb]

1. Deaktivierung per WebIF ist meiner Meinung nach Pflicht. Werde ich nachher vorsehen. Dann kann man nämlich die ganze Aktivierung unter menuconfig ersparen. Die Checks selbst würden dann unter "automount-patch" reinfallen und sollen immer im Patch drin sein.
2. Für ntfs gibt es sowas hier: http://www.linux-ntfs.org/doku.php?id=ntfsprogs Übrigens, eine nette Seite allgemein über ntfs. Mal eben per google gefunden. Jemand von unseren Kompilierungsexperten sollte bitte ein Auge darauf werfen, ob es kompliziert wäre es ins FREETZ aufzunehmen.
3. Zur Auslagerung war es so gemeint, dass wenn es im trunk bereits gewesen wäre, hättest du es evtl. leichter gehabt, weil du nicht in run_mount, sondern in libmodmount.sh editieren würdest. Aber es ist noch nicht im trunk, von daher egal.

MfG

 

[cuma]

1. Deaktivierung per WebIF ist meiner Meinung nach Pflicht.

Bitte, bitte, "aktivierbar" machen.

 

[hermann72pb]

Ich meinte damit, dass man es nicht per menuconfig permanent aktiviert und danach sich ärgert, dass die Platte mal 2-3 Stunden lang gecheckt wird, sondern, dass man es spätestens nach dem zweiten Konflikt mit der Ehefrau bewusst deaktivieren kann, ohne neues Image zu flashen. Wie ihr sieht, bin ich immer noch nicht richtig der Fan davon es permanent durchzuführen, würde aber eurem Druck und Wunsch nachgeben und mich damit abfinden, dass man es aktivieren und deaktivieren kann.

MfG

 

[coolphoenix]

wenn man die option im menuconfig wegnimmt, müsste das webinterface immer überprüfen, ob die checkprogramme vorhanden sind oder nicht (denn sonst macht es kein sinn, die option einzublenden).

andersrum (mit patch) würde es die option im webiface zur deaktivierung nur geben, wenn wirklich e2fsck installiert ist (und das webiface müsste nicht immer checken). außerdem erleichtert es für den benutzer die auswahl der programme, der muss sich nicht überall durchkämpfen, sondern der menuconfig-eintrag wählt automatisch alle nötigen programme.

wobei ich nicht weiß, wozu man es deaktivieren muss können - was gibt es denn für ein szenario, dass ich eine platte "mal eben" ohne check mounten will, obwohl ich mich eigentlich dafür entschieden habe (durch auswahl des patch), meine unsauberen platten zu fixen.

und zum fixen von ntfs: http://www.linux-ntfs.org/doku.php?id=ntfsck

Bitte, bitte, "aktivierbar" machen.

kommt ja nur auf den defaultwert an, wenn es soeine möglichkeit geben soll.

aber nochmal: warum sollte man es on the fly deaktivieren / aktivieren wollen? ist doch nur ein zusätzlicher (unnützer) schalter, der das interface unübersichtlicher macht. wenn man nur "ab und zu" mal seine platte checken will, kann man das auch per console machen - da braucht man keinen automatischen-check-patch.

edit:

wir können ja ein interface bauen, wo man einträgt, wann die "frau" zur arbeit ist / bei schwiegereltern / beim arzt, und dann wird der automatische check aktiviert und sonst nicht

 

[hermann72pb]

wir können ja ein interface bauen, wo man einträgt, wann die "frau" zur arbeit ist / bei schwiegereltern / beim arzt, und dann wird der automatische check aktiviert und sonst nicht

Genau dahin zielte meine ursprüngliche Idee, die Tests regelmässiger per cron zu machen, dafür aber auf die Tests beim Hochfahren zu verzichten. Und genau dafür braucht man diese Optionalität. Wie gesagt, entweder klassich beim hochfahren, oder eben nachts zu definierten Zeiten.
Zum menuconfig /webif. Es wird nicht unübersichtlich, wenn man dafür eine eigene cgi macht. Dort wirst du dann alles einstellen können. Man könnte/sollte diese cgi dann optional machen. Die checkroutinen unter fs_mount() sollen entweder auf das Vorhandensein von dieser cgi einen check machen oder eben auf die einzelnen check-Programme, oder sogar beides. Ich neige letzte Zeit dazu fast überall ein check auf das Vorhandensein von dem einen oder dem anderen Skript vor der Ausführung einzuführen. In diesem konkreten Fall klaut es nicht besonders viel an Performance, dafür musst du aber nicht mit den Abhängigkeiten unter menuconfig besonders aufpassen und sich mit fwmod überlegen, wie man eine oder andere Zeile entfernt/einfügt.

MfG

 

[Silent-Tears]

Ich bleib ja bei meiner Meinung, dass eine eindringliche Mail rausgeschicikt werdne sollte, oder eben auf der Statusseite signalisiert, und/oder per blinkender Lampe oder so etwas. Ein kompletter fsck auf einer z.B. TB-Platte ist grauenhaft....

 

[cuma]

Man könnte auch den avm-mailer missbrauchen und eine nette eMail verschicken, dass man die Platte checken soll

 

[Silent-Tears]

Habe ich in dem anderen Thread vorgeschlagen....

 

[cuma]

Cool, einer Meinung :-]

 

[coolphoenix]

wenn man die platte gar nicht auf der box checken will, dann ist das eine ganz andere baustelle - dann braucht man nicht e2fsck o.ä. tools, sondern muss nur irgendwie herausfinden, ob die platte unsauber ist.

ext2/3: flag needs_recovery ist vor dem mounten gesetzt, geht z.b. mit "tune2fs -l"
ntfs: gibt es soein pendant zum needs_recovery? wenn nicht, dieser "online-check", der nachts laufen soll
vat: ebenfalls "online-check"?

zumindest im ext2/3-fall braucht man zum anzeigen also kein check-tool/e2fsck (aber was anderes/tune2fs).

dieser patch hier soll ja nur dafür da zu sein, eine platte beim mounten zu überprüfen, wenn sie unsauber ist (und mehr erst mal nicht). bei ext2/3 ist das durch needs_recovery einfach herauszufinden und deshalb implementiert.

wir sollten die diskussion zur anzeige / mail rausschicken / usw. lieber im anderen thread fortsetzen (damit alles an einer stelle zu finden ist) und hier nur darüber diskutieren, wie man ein checken der platten auf der box vor dem mounten realisiert bzw. ob sowas notwendig ist.

bis jetzt haben wir doch eigentlich nur:

pro: man hat ein konsistentes dateisystem
contra: dauert zu lange auf der box

beides argumente, die für sich stehen. die einen finden es definitiv zu lange, wenn sie 30min auf das mounten warten müssen, falls die box abgestürzt ist - andere (oder nur ich? *g*) möchten ein konsistentes dateisystem, auch wenn das halt beim checken dauert.

nach einiger überlegung bin ich nun doch dafür, eine optionen zur deaktivierung irgendwo im webiface zu haben. aber zusätzlich die auch menuconfig option. also so:

option im menuconfig, die automatisch alle abhängigkeiten klärt und im webinterface die möglichkeit gibt, den check zu deaktivieren. zusätzlich eine option, nach auswahl des patches, wo man den default-wert einstellt (also ob es von vornerein im webiface deaktiviert ist bei fehlender variable im flash auf der box).

 

[Silent-Tears]

Mir schwebt da eher ein mehrstufiges Konzept vor. Ein Webinterface, in dem man das Verhalten einstellen kann zwecks "needs recovery" (oder ähnlichem). Warnen, zu einer festgelegten Zeit alles stoppen, umounten und durchlaufen lassen oder sofort nach dem Boot. Wobei ich dieses "zu irgendeiner Uhrzeit" eher mit "sofort beim Boot" gleichsetzen würde und einen crontab dazupacken würde, der die Box neu startet zur angegebenen Zeit.

Hat also weiterhin was miteinander zu tun, bzw. muss irgendwo vereinigt werden.

ntfs übrigens hat ein "dirty-flag", aber kein sauberes Recovery unter Linux. Dann nur ein "dirty flag entfernen, ebenso wie das journal und damit hat sich das" (reicht aber meist). Ob FAT sowas hat, weiss ich nicht, aber ich erinnere mich an alte Windows-Zeiten (ME ff), wo so etwas tatsächlich als "Feature" galt. Aber ich glaube wirklich erst dann.

 

[hermann72pb]

@Silent-Tears: Mit dem Reboot gebe ich dir Recht, dass man damit vieles erschlagen könnte, aber ich würde nicht auf eine einfache Check-Möglichkeit ohne Reboot verzichten wollen. Denn ich bin mir fast 100% sicher, dass die Prüfung bei der hier vorgeschlagenen Lösung irgendwo mittendrin in der rc.S-Schleife abläuft (oder Ähnliches). Dadurch ist die Box zu dem Zeitpunkt höchstwahrscheinlich nicht verfügbar. Wenn man allerdings mehrere Partitionen an dem Medium hat und diese Partitionen so vernünftig aufteilt, dass nicht überall aktive Programme und Logs herumliegen, dann wäre es möglich die Check-Routinen bei der laufenden Box wenigstens für die anderen Partitionen durchzuführen. Und wenn man noch zusätzlich kritische Dienste eintragen würde, die den Zugriff auf eine bestimmte Partition brauchen irgendwo eintragen und diese Dienste dann während der Reparatur stoppen und danach starten, dann wird die Box während der Prüfung noch mehr verfügbar (ok, nicht ganz, aber immerhin beschränkt).
Deswegen sehe ich da folgende Möglichkeiten/Tätigkeitsfelder, zu denen ich gleich die Zuständigkeiten eintrage:
1. Check beim Hochlaufen. Das diskutieren wir hier und das verfolgt coolphoenix weiter.
2. RO-Check ohne unmount (um die Fehler und Inkonsistenzen festzustellen, aber nicht korrigieren). Das verfolge ich, weil keiner hier dafür ernsthaft interessiert ist, obwohl ich es als viel versprechend finde. Diskussion irgendwo anders, nicht hier.
3. dirty-Flag auswerten. Verfolge ich ebenfalls. Vielleicht kann man dafür und für Punkt 2 ein eigenes Thread aufmachen. Ich sehe die dirty-Methode zwar auch als interessant an, aber weiß nicht, ob es 2 vollständig ersetzt. Diskussion ebenfalls nicht hier.
4. Eine eigene cgi-gui erstellen (als Paket/CGI-Paket), in der wir alle Einstellmöglichkeiten haben. Das könnte ich übernehmen. Lass uns es aber hier nur insoweit diskutieren, wie es notwendig ist, sonst im anderen Thread. In dieser CGI/diesem Paket sollten schon einige Skripte im Hintergrund laufen, damit man das Ganze automatisiert und in die cron-Tabelle einträgt.
5. Checkmöglichkeiten am laufenden System (ohne reboot) ermöglichen. Das ist eine sehr große Baustelle, die man schritt-für-schritt angehen sollte. Auch am besten irgendwo anders diskutieren.

Somit haben wir alles geklärt und aufgeteilt.

MfG

 

[coolphoenix]

Denn ich bin mir fast 100% sicher, dass die Prüfung bei der hier vorgeschlagenen Lösung irgendwo mittendrin in der rc.S-Schleife abläuft (oder Ähnliches). Dadurch ist die Box zu dem Zeitpunkt höchstwahrscheinlich nicht verfügbar.

falls du damit meinen patch meinst: nein. box ist normal verfügbar, während im hintergrund platten gecheckt werden.

kümmer mich gerne weiterhin um das checken direkt beim mounten. werde demnächst irgendwann das checken von fat auch einbauen - oder soll ich erst warten, wenn run_mount() (usw.) ausgelagert ist?

 

[hermann72pb]

Es wäre besser, wenn wir möglichst schnell run_mount() auslagern. Dann kannst du in "unserer" Datei rumeditieren, anstatt in AVM-Sachen rumzupatchen. Ich hänge momentan noch an meiner mounted.cgi. Wenn ich damit fertig bin, komme ich zu run_mount-Auslagerung zurück.

MfG