Das root-(EXT4)-Filesystem wird ständig überwacht und schreibt einen Fehler in die Logfiles.
Dazu gibt es ein einstellbares "error-behavior" (continue - remount ro - panic) und in Linux allgemein ein "panic behavior" das zwischen reboot und panic console konfigurierbar ist. In systemd ist dabei auch noch das Umschalten in das emergency service vorgesehen.
In den Pi Distributionen ist das error behavior auch "continue" voreingestellt, sidass sich der hostadmin um die Gesunfheit des Filesystems selbst kümmern muss, insbes. im 24/7/365 Dauerbetrieb.
Die Pi Distributionen haben im Regelfall auch kein Mailprogramm vorinstalliert, sodass dem hostafmin keine System Errormails ins Mailverzeichnis /var/mail/root eingelegt werden.
Servus !
Nimm eine SSD, denn die kann man mit S.M.A.R.T überwachen. Bei SD-Karten ist das nicht vorgesehen.
Das root-(EXT4)-Filesystem wird ständig überwacht und schreibt einen Fehler in die Logfiles.
Dazu gibt es ein einstellbares "error-behavior" (continue - remount ro - panic)
Wie muss ich mir das vorstellen? Hänge ich das Ext4-Filesystem mit bestimmten Parametern über die fstab ein?
Quotein Linux allgemein ein "panic behavior" das zwischen reboot und panic console konfigurierbar ist. In systemd ist dabei auch noch das Umschalten in das emergency service vorgesehen.
Das klingt so als ob der erste Punkte eine Funktion von ext4 ist und das hier eine Funktion von Linux wie reagiert werden soll, falls von der Ext4-Überwachung ein Fehler auftritt?
Wie muss ich mir das vorstellen? Hänge ich das Ext4-Filesystem mit bestimmten Parametern über die fstab ein?
Die meisten Parameter des EXT4 Filesystems werden schon beim Erstellen ("Formatieren") des Filesystems in die Metadaten des Filesystems eingetragen. Teilweise können die Parameter nachträglich abgeändert werden.
< man ext4 >
< dumpe2fs -h /dev/mmcblk0p2 >
< tune2fs /dev/mmcblk0p2 >
u.A.
Servus !
Die meisten Parameter des EXT4 Filesystems werden schon beim Erstellen ("Formatieren") des Filesystems in die Metadaten des Filesystems eingetragen.
BTW: Beim ext4-Dateisystem wird _standardmäßig_, das Prüfen mit e2fsck, nicht aktiviert. Z. B.:
QuoteDisplay More:~$ sudo tune2fs -l /dev/sdd2 | grep -iE 'interval|checked|max|has_journal'
Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file dir_nlink extra_isize
Maximum mount count: -1
Last checked: Mon Sep 14 09:43:52 2020
Check interval: 0 (<none>)
Lt. der manpage von tune2fs:
QuoteIf you are using journaling on your filesystem, your filesystem will never be
marked dirty, so it will not normally be checked.
EDIT:
BTW: Bei FreeBSD muss das (manuelle) "Prüfen" nicht im ausgehängten Zustand gemacht werden, was gut ist für 24/7-Systeme (nach einem evtl. erforderlichen check ist ein reboot erforderlich):
BTW: Beim ext4-Dateisystem wird _standardmäßig_, das Prüfen mit e2fsck, nicht aktiviert.
Das ist so gewollt, weil durch "fsck.repair=yes" in der cmdline.txt bei jedem Booten ein fsck erzwungen wird. (und ein repair nur am ungemounteten Filesystem möglich ist)
Lt. manpage von e2fsck
...
-f Force checking even if the file system seems clean.
...
Servus !
bei jedem Booten ein fsck erzwungen wird.
Sprich man muss dann in gewissen Intervallen einen Reboot erzwingen damit das passiert.
Nimm eine SSD, denn die kann man mit S.M.A.R.T überwachen. Bei SD-Karten ist das nicht vorgesehen.
Sicherlich eine gute Idee. Allerdings bekommt man damit nicht mit wenn es Filesystemprobleme gibt. Dazu braucht man wo wie ich es verstehe fsck.
ähnlich wie es bei echten Servern gemacht wird
Dort nutzt man ueblicherweise ein RAID und erstellt regelmaessige Backups.
Das ist so gewollt, weil durch "fsck.repair=yes" in der cmdline.txt ...
Beim PI, ja, ... aber das ext4-Dateisystem wird ja nicht nur mit dem PI (/boot/cmdline.txt) benutzt.
D. h., mag sein, dass es so gewollt ist, aber der Grund bzw. die Ursache ist nicht dieser Eintrag, in der cmdline.txt des PI. Es geht m. E. hier doch eher um die Folgen bzw. was man beachten muss, wegen dem _nicht_ standardmäßigen Prüfen, bei ext4.
Sprich man muss dann in gewissen Intervallen einen Reboot erzwingen damit das passiert.
Solange das Filesystem im Dauerbetrieb fehlerfrei läuft, brauchst Du nicht rebooten. Es reicht, wenn Du periodisch (täglich, wöchentlich, monatlich) die Gesundheit checkst (ohne repair), wie es z.B. von mir in Quick & Dirty root - FS check aufgezeigt wurde.
Servus!
