USB-Stick und SD-Karte permanent auf Probleme prüfen

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • Hallo,

    vor ein paar Wochen ist auf meinem 24/7 laufenden Pi die SD-Karte abgeraucht. Ich hatte ein aktuelles Backup und das war kein Problem. Gibt es (ähnlich wie es bei echten Servern gemacht wird) die Möglichkeit beides permanent zu überwachen und ggf. eine Meldung auszugeben?

  • 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 !

    RTFM = Read The Factory Manual, oder so

  • 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?

    Zitat

    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.

    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 !

    RTFM = Read The Factory Manual, oder so

  • 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:

    Zitat

    If 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
    Zitat

    FreeBSD 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."

    Ein manuelles "fsck -y /" war hier nicht erforderlich.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

    Einmal editiert, zuletzt von rpi444 (3. August 2022 um 10:14)

  • 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 !

    RTFM = Read The Factory Manual, oder so

  • 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.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • 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!

    RTFM = Read The Factory Manual, oder so

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!