sudo e2fsck -nfv /dev/mmcblk0p2 zeigt Filesystemfehler an am laufenden System - alles OK wenn der Check offline erfolgt

framp · August 1, 2024 at 8:35 PM

Wegen einer anderen Sache bin ich mal dem Tut von RTFM gefolgt und war erschreckt ueber die Fehler die mir gemeldet wurden. Lasse ich die Option -f weg wird kein Fehler reportet.

Daraufhin habe ich das System runtergefahren und an einem anderen System geprueft und da tauchten keine Filesystemfehler auf

Mir ist auch aufgefallen dass die Fehlermeldungen jetzt nach einer gewissen Zeit anders aussehen. D.h. fuer mich dass man die Option -f mit Vorsicht geniessen muss - jedenfalls wenn das Filesystem gemountet und aktiv ist. Offensichtlich sind Laufzeitaenderungen auf dem Filesystem nicht atomar und werden mit -f bemerkt. Ehrlich gesagt haette ich vermutet dass alle Filesystemaenderungen atomar sind. Aber vielleicht ist das auch der Sinn des ext4 Journals - solche nicht atomaren Transaktionen reparieren zu koennen.

Oder habe ich hier was falsch verstanden?

Bot · Vor 5 Minuten

sudo e2fsck -nfv /dev/mmcblk0p2 zeigt Filesystemfehler an am laufenden System - alles OK wenn der Check offline erfolgt? Schau mal ob du hier fündig wirst!

RTFM · August 1, 2024 at 9:42 PM

Die -f (force) Option ist bei journalisierenden Filesystemmen immer erforderlich, da der Filesystemstatus "Clean",oder "Clean with errors" auch dann zurückgegeben/angezeigt wird, wenn alle geänderten Metadaten im Journal noch durchgehend gespeichert sind. Ohne -f könnte das "repair" nicht angestossen werden und das Journal wird immer größer.

Servus !

framp · August 1, 2024 at 10:36 PM

Quote from RTFM

Die -f (force) Option ist bei journalisierenden Filesystemmen immer erforderlich, da der Filesystemstatus "Clean",oder "Clean with errors" auch dann zurückgegeben/angezeigt wird, wenn alle geänderten Metadaten im Journal noch durchgehend gespeichert sind.

Interessant. D.h. die Info dass das FS OK ist (ohne die -f Option) setzt voraus dass alle noch offenen Transaktionen im Journal stehen.

Quote from RTFM

Ohne -f könnte das "repair" nicht angestossen werden und das Journal wird immer größer.

Verstehe ich so ganz: Auch wenn ich nicht regelmaessig mit der Option -f das FS checke kann ich doch mein Filesytem mit Hilfe des Journals reparieren

Und warum wird as Journal dann immer groesser?

Bot · Vor einem Moment

RTFM · August 2, 2024 at 9:59 AM

Ein "rollback" des Journals zum repair wird nur dann erfolgreich sein, wenn die Sektoren der "alten" Inodes noch nicht überschrieben wurden. Auch das Journalfile selbst darf noch nicht korrupt geworden sein.

Servus !

framp · August 2, 2024 at 10:10 PM

Ist Dein Tut nicht etwas irrefuehrend mit der Option -f ?

Das am laufenden System ausgefuehrt zeigt wie ich verstehe meist Fehler an. Wenn dann die Option -f offline genutzt wird ist doch alles OK. Jedenfalls ist das meine Erfahrung an meinen 3 aktiven Raspis. Ich dachte erschreckt bei allen Raspis sein das Filesystem reparaturbeduerftig - und letztendlich war es keines nachdem ich den Test offline ausgefuehrt habe.

RTFM · August 3, 2024 at 12:15 AM

Quote from framp

irrefuehrend mit der Option -f ?

Nein, bei einem journalisierenden Filesystem brauchst Du immer die "force" Option zum FS Check. Egal, ob die Partition gemounted, oder ungemounted ist.

Aus man < e2fsck >:

-f Force checking even if the file system seems clean.

Servus !

Bot · Vor einem Moment

framp · August 3, 2024 at 10:03 AM

Quote from RTFM

-f Force checking even if the file system seems clean.

Das habe ich gelesen aber nicht verstanden. D.h. da wird das Journal nicht berücksichtigt sondern der aktuelle Stand getestest.

Ich verstehe einfach nicht warum offline keine Fehler gemeldet wurden. Das Filesystem muss doch weiterhin nicht OK sein und mit -f Fehler melden. Das passiert aber nicht

streithausen · August 4, 2024 at 9:12 AM

Mache bitte kein fschk mit -force auf einem gemounteten Dateisystem.

framp · August 4, 2024 at 9:43 AM

Nee. Keine Angst. Das weiss ich

Aber guter Hinweis für Mitleser die das Tut nicht gelesen haben: In dem Tut steht man soll -f zusammen mit -n nutzen. Dann wird nur getestet und nichts auf dem Filesystem geaendert.

Ich Frage mich auch so langsam wozu die Option -f eigentlich existiert.

Bot · Vor einem Moment

streithausen · August 4, 2024 at 10:01 AM

für ein resizefs Obwohl ein clean gezeigt wied verlangt eine Vergrösserung/Verkleinerung ein Dateisystemcheck.

RTFM · August 4, 2024 at 12:31 PM

Quote from framp

Ich Frage mich auch so langsam wozu die Option -f eigentlich existiert.

Weil es viele Linux Distributionen gibt und niemand verpflichtet ist, ein EXT4 Filesystem mit dem errors- behavior "continue" zu installieren und zu betreiben. Pi-OS und Debian (von den anderen weiss ichs nicht) haben bei der Erstellung eines EXT4 Filesystems continue voreigestellt, sodass infolge der Journaleintragungen trotz Fehlern das Filesystem rw weiterbetrieben wird mit dem Filsystemstatus clean, oder clean with errors. Wenn e2fsck den Filesystemstatus zum Anlass nimmt den fsck zu überspringen, wird natürlich kein Fehler angezeigt und würde auch kein repair durchgeführt.

Deshalb ist -ein "force" -f erforderlich, weil (infolge des Journals) ein ext4 FS clean ausschauen könnte (... even it seems clean)

Meine "Anleitung" versteht sich als "Quick + Durty" und ersetzt keineswegs die Systembefehle dumpe2fs, tune2fs, debugfs samt deren man.pages. Es ist auch ein dumpe2fs Beispiel B. angeführt das über den grep Filter nur nach der Zeile des ersten verwaisten Inode sucht. Mit < sudo dumpe2fs -h /dev/mmcblk0p2 > bekommst Du den gesamten Ext4 Metadaten-Header angezeigt.

Servus !

framp · August 4, 2024 at 12:47 PM

Quote from RTFM

Meine "Anleitung" versteht sich als "Quick + Durty" und ersetzt keineswegs die Systembefehle dumpe2fs, tune2fs, debugfs samt deren man.pages.

Verstehe ich. Es hat mich nur ziemlich verwundert dass im gemounteten Zustand mit -f Fehler angezeigt wurden und ich schon dachte - "Schei**e FS im Ar***" - und dann im ungemounteten Zustand nichts mehr an Fehlern mit -f berichtet wurden.

D.h. man wird alerted dass da was am FS nicht in Ordnung ist und es stellt sich heraus dass doch alles OK ist.

Bot · Vor einem Moment

framp · August 5, 2024 at 8:45 PM

Quote from framp

D.h. man wird alerted dass da was am FS nicht in Ordnung ist und es stellt sich heraus dass doch alles OK ist.

Ich habe immer noch nicht verstanden warum das passiert Kann es daran liegen dass andere SD Karten genutzt werden und der Controller auf der SD Karte unterschiedlich arbeitet/cached?

Code

pi@idefix:~ $ sudo e2fsck -nfv /dev/mmcblk0p2
e2fsck 1.47.0 (5-Feb-2023)
Warning!  /dev/mmcblk0p2 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong (1213503, counted=1213496).
Fix? no

Free inodes count wrong (376089, counted=376082).
Fix? no


       82663 inodes used (18.02%, out of 458752)
          38 non-contiguous files (0.0%)
          63 non-contiguous directories (0.1%)
             # of inodes with ind/dind/tind blocks: 0/0/0
             Extent depth histogram: 76590/8
      620481 blocks used (33.83%, out of 1833984)
           0 bad blocks
           1 large file

       70329 regular files
        6167 directories
           0 character device files
           0 block device files
           0 fifos
         329 links
        6165 symbolic links (6064 fast symbolic links)
           0 sockets
------------
       82990 files

Display More

Code

pi@asterix:~ $ sudo e2fsck -nfv /dev/mmcblk0p2
e2fsck 1.47.0 (5-Feb-2023)
Warning!  /dev/mmcblk0p2 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
Pass 1: Checking inodes, blocks, and sizes
Deleted inode 3538964 has zero dtime.  Fix? no

Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  -(3432342--3432418)
Fix? no

Free blocks count wrong for group #104 (11642, counted=11565).
Fix? no

Free blocks count wrong (13417124, counted=13414795).
Fix? no

Inode bitmap differences:  -3538964
Fix? no

Free inodes count wrong (3743696, counted=3743697).
Fix? no

Block bitmap differences: Group 104 block bitmap does not match checksum.
IGNORED.

/dev/mmcblk0p2: ********** WARNING: Filesystem still has errors **********


      139312 inodes used (3.59%, out of 3883008)
         166 non-contiguous files (0.1%)
          98 non-contiguous directories (0.1%)
             # of inodes with ind/dind/tind blocks: 0/0/0
             Extent depth histogram: 132621/56
     2097500 blocks used (13.52%, out of 15514624)
           0 bad blocks
           1 large file

      117126 regular files
       15448 directories
           0 character device files
           0 block device files
           2 fifos
         342 links
        6724 symbolic links (6622 fast symbolic links)
           1 socket
------------
      139643 files

Display More

Participate now!