USB-Stick und SD-Karte permanent auf Probleme prüfen
-
Reinhart -
20. Juli 2022 um 14:30 -
Unerledigt
-
-
USB-Stick und SD-Karte permanent auf Probleme prüfen? Schau mal ob du hier fündig wirst!
-
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 !
-
-
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?
Zitatin 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.:
Zitat:~$ 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:
ZitatIf 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):
Spoiler anzeigen
ZitatFreeBSD has properly working forced unmount, so you don't really need to do
this at boot. Just log in (remotely), remount rootfs as read-only (mount -fur /), do
fsck manually (fsck -y /) and then reboot the machine.
Zitat:~ # fsck_ffs -F /; echo $?
7
# status code 7 = "The -F option was used and the file system is clean."
Zitat:~ # fsck_ffs -C /; echo $?
** /dev/ufs/rootfs (NO WRITE)
** Last Mounted on /
** Root file system
** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups
66024 files, 946277 used, 2803994 free (186 frags, 350476 blocks, 0.0% fragmentation)
0
Ein manuelles "fsck -y /" war hier nicht 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.
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!
Jetzt mitmachen!
Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!