Führt Debian automatisch fsck nach crash durch?

[c1ue]

Hab dazu nix gescheites im Netz gefunden:

Bei mir wacht manchmal die Kiste ausm standby nicht wieder richtig auf, oder schmiert ab, wenn ich in den standby wechsele, oder auch gerne einfach mal beim Hochfahren. Dabei wird das Dateisystem zwangsläufig unsauber unterbrochen.

Daher meine Frage:

Führt Debian (Buster) automatisch nen check nachm crash durch, wenn ich neu boote?

Und wie siehts eigentlich mit USB-Sticks/Platten aus, werden die auch automatisch beim mounten überprüft?

Vielen Dank im voraus.

[KP97]

Führt Debian (Buster) automatisch nen check nachm crash durch, wenn ich neu boote?

Das kommt auf den Eintrag in der fstab an. Der letzte/vorletzte Eintrag veranlaßt einen Check beim Start. Man fstab gibt Auskunft.
Bei USB hat man meist keinen Eintrag in der fstab, da werkelt der Dateimanager.
Da mußt Du entsprechend nachsehen.

[pferdefreund]

Aber da habe ich schon die Meldung Filesystem not cleanly unmounted, please run fsck - gesehen. Zumindest merken tut es Debian wohl auch bei USB.

[MSfree]

Aber da habe ich schon die Meldung Filesystem not cleanly unmounted, please run fsck - gesehen.

Diese Meldung kommt, wenn der normale fsck-Lauf meint, die Dateisystemfehler nicht selbstständig bereinigen zu können. fsck wird aber in jedem Fall aufgerufen, in dem das Daeisystem als "dirty" markiert ist.

Die "dirty"-Markierung geschiet im Dateisystem auf der Platte beim Mount und wird beim Unmount wieder auf "clean" gesetzt, so daß gewährleitet ist, daß nach eine Crash das Dateisystem als "dirty" markiert ist.

[c1ue]

So, hab meine fstab dahingehend angepasst, dass jetzt da ne 1 am Ende der Zeile steht:

/dev/sda3 / ext3 rw,relatime,data=ordered 0 1

Nachm Neustart schien es diesmal etwas länger gedauert zu haben, bis er das FS mounted hat.

Hab dann mal mit journalctl -b |grep sda nachgeschaut, aber da stand nix von fsck, check, clean, root, etc.

journalctl -b -2 |grep sda zeigte jedenfalls keinen Unterschied zum jetzigen Zustand an.

Fragen:

1. Habe ich jetzt eigentlich jahrelange mit inkonsistenten Dateisystemen gelebt, aber ohne dabei jemals eine einzige Datei verloren zu haben?

2. Woran kann ich denn sehen, ob Debian mein FS nun checkt hat?

3. Dadurch, dass ich aus der 0 am Ende des fstab Eintrages nun eine 1 gemacht habe, checked der jetzt jedesmal mein FS beim hochfahren?

Vielen Dank für Eure Hilfe bisher.

[OrangeJuice]

Du könntest zum testen auch fsck in grub eintragen, z.B.

Code: Alles auswählen

GRUB_CMDLINE_LINUX_DEFAULT="fsck.mode=force fsck.repair=yes"

Wenn fsck beim Start ausgeführt wird, solltest du es sehen(Fortschrittsbalken).

[c1ue]

Schon, aber ich will ja nicht, dass der jedes Mal n check macht, sondern nur, wenn nicht sauber runtergefahren worden ist.

[ohnex]

hallo

Hab dann mal mit journalctl -b |grep sda nachgeschaut, aber da stand nix von fsck, check, clean, root, etc.

warum grepst du nach dem device und nicht nach fsck ? journalctl -b |grep fsck.

1. Habe ich jetzt eigentlich jahrelange mit inkonsistenten Dateisystemen gelebt, aber ohne dabei jemals eine einzige Datei verloren zu haben?

Soweit ich das noch in Erinnerung habe wird standardmäßig alle paarunddreißig mounts oder alle xxx tage beim Systemstart geprüft.

Mit

Code: Alles auswählen

tune2fs -l /dev/[i]dein root device[/i]

kann man sich die Einstellungen ansehen.

3. Dadurch, dass ich aus der 0 am Ende des fstab Eintrages nun eine 1 gemacht habe, checked der jetzt jedesmal mein FS beim hochfahren?

Ich denke nicht , bin mir aber nicht ganz sicher, wenn du aber den Zeitintervall auf 1 setzten würdest dann sollte bei jedem Systemstart eine Prüfung erfolgen.

Code: Alles auswählen

tune2fs /dev/sdx  -i 1 

ciao

[MSfree]

Eine Schnellprüfung erfolgt immer. Im Dateisystem selbst ist hinterlegt, ob das Dateisystem sauber ausgehängt wurde, oder, wie im Fall eines Crashes, nicht. Ergibt diese Schnellprüfung, daß das Dateisystem nicht sauber ist, wird das root-Dateisystem auf jeden Fall gecheckt. Schlägt das Fehl, wird man aufgefordert, das Dateisystem manuell zu checken.

Alle anderen Dateisystem werden abhängig vom Eintrag in der fstab gecheckt. Hier gibt es verschiedene Wege, je nachdem, ob gecheckt werden soll, oder, wenn nicht, wie dann verfahren werden soll. Eine Möglichkeit ist, unsaubere Dateisysteme read-only zu mounten.

Die erwähnten Intervalltests erfolgen, wenn nach einem Reboot das Checkintervall überschritten wurde, also mehr als x-mal ohne Check gemountet wurde oder der letzte Check y-Tage zurück liegt. Diese Checks erfolgen auch dann, wenn das Dateisystem sauber ausgehängt wurde. (Meiner Meinung nach ist es aber überflüssig, saubere Dateisystem zu checken, ich schalte diese Intervalle generell ab)

Letztlich braucht man gar nichts an der Standardinstallation zu ändern. Der Schnellcheck auf sauberes aushängen findet immer statt, denn die ist Voraussetzung dafür, das Dateisystem read-write zu mounten. Alles andere wird dann sowieso automatisch durchgeführt.

[c1ue]

Letztlich braucht man gar nichts an der Standardinstallation zu ändern. Der Schnellcheck auf sauberes aushängen findet immer statt, denn die ist Voraussetzung dafür, das Dateisystem read-write zu mounten. Alles andere wird dann sowieso automatisch durchgeführt.

Hey, danke! Das war die Info, die ich gesucht habe. Es hätte mich auch gewundert, wenn dies nicht bei Debian der Fall gewesen wäre.

Gibts da irgendwo was zum Nachlesen? Ich habe, wie gesagt, nichts brauchbares dazu finden können.

[ingo2]

Habe diesen Thread erst jetzt gelesen, aber da stellt sich mir die Frage:

Ist der ganze "fsck" bei ext4 nur snake oil?

Ich habe mal überschlagen für meine 1TB SSD:
Ein voller SMART-Selftest für die ganze SSD dauert 512 Minuten = 30.000 Sekunden.
Belegt ist die SSD u.a. bei mir mit einer Partition mit 920 GB Größe, davon sind 490 GB belegt.
Was ich so über ext4 finden konnte, belegen allein die Inodes standardmäßig 1,6% des Speicherplatzes.
(s. https://serverfault.com/questions/28231 ... ad-in-ext4)
Allein die belegten Inodes machen also knapp 8 GB aus. Das Journal braucht auch noch Platz.

Ein fsck der Partition beim Booten dauert ca. 2-3 sec.
Wenn also nur alle belegten Inodes eingelesen werden, dauert das bei maximaler SATA-Geschwindigkeit von ca. 500 MB/s allein 16 Sekunden - und da ist noch nichts überprüft

Oder denke ich da falsch?
Ingo

[MSfree]

Ist der ganze "fsck" bei ext4 nur snake oil?

Nein, sicher nicht.

Der Schnelltest, der beim Booten durchgeführt wird, prüft im Grunde nur das Dirty-Flag und spielt im Falle, daß das Dateisystem "verschmutzt" ist, das Journal ein. Das Journal ist übrigens eher klein, irgendwas um 4-128MByte.

Nur das "große" fsck durchläuft einen kompletten Konsistenzcheck über alle iNodes..., was dann auch mal in den Minutenbereich gehen kann.

[ingo2]

Ist der ganze "fsck" bei ext4 nur snake oil?

Nein, sicher nicht.
Nur das "große" fsck durchläuft einen kompletten Konsistenzcheck über alle iNodes..., was dann auch mal in den Minutenbereich gehen kann.

Hast du eine Idee, wie ich das anstoßen kann?
Wenn ich mich recht erinnere, war das früher mal Standard, wenn man mit

Code: Alles auswählen

touch /forcefsck

das aktiviert hat und in der fstab in der 6. Spalte eine entsprechende Zahl stand.
Auch, wenn man das mit z.B.

Code: Alles auswählen

tune2fs -C 1 <Partition>

aktiviert hatte.

Klappt jetzt alles nicht mehr

EDIT:
Der kurze Check, ob das Filesystem "dirty" ist, tut also garnichts, denn falls es dirty ist, wird sowieso geprüft. Ist genauso, als wenn ich ein Backup von irgendwas mache und mich dann darauf verlasse, das alles ok ist - ohne "verify".

[OrangeJuice]

Hier ist das ganz gut erklärt, finde ich. Bei mir klappt es jedenfalls, ich lasse es aber im Moment auf Auto, vorher war force in Grub eingestellt, letzter check ist wohl am 15.2. gewesen. Ich weiß aber nicht ob dir das etwas weiter hilft.

Code: Alles auswählen

tune2fs -l /dev/sdXY | grep checked

Code: Alles auswählen

nano /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="fsck.mode=force fsck.repair=yes"

With old sysvinit and Upstart, users could force a disk check on next reboot using a simple command (sudo touch /forcefsck), but that's no longer the case nowadays, with most Linux distributions using systemd. This article explains how to force fsck to run at boot time in two ways, which work with systemd. Quelle

[MSfree]

Zu tune2fs habe ich noch folgenden Interessanten Absatz im Manual gefunden:

-c max-mount-counts
Adjust the number of mounts after which the filesystem will be checked by
e2fsck(8). If max-mount-counts is 0 or -1, the number of times the filesystem is
mounted will be disregarded by e2fsck(8) and the kernel.

Staggering the mount-counts at which filesystems are forcibly checked will avoid
all filesystems being checked at one time when using journaled filesystems.

You should strongly consider the consequences of disabling mount-count-dependent
checking entirely. Bad disk drives, cables, memory, and kernel bugs could all corrupt
a filesystem without marking the filesystem dirty or in error. If you are
using journaling on your filesystem, your filesystem will never be marked dirty, so
it will not normally be checked. A filesystem error detected by the kernel will
still force an fsck on the next reboot, but it may already be too late to prevent
data loss at that point.

Ich war eigentlich der Annahme, daß das Dirty-Flag immer gesetzt wird, unabhängig davon, ob das FS ein Journal hat oder nicht. Da lag ich wohl im Irrtum.

Dennoch habe ich es schon öfter beobachtet, daß mein Rechner zumindest das Journal einspielt, nachdem der Rechner nicht ordnungsgemäß runtergefahren wurde. Hier ersetzt wohl der Zustand des Journals das Dirty-Flag und die Dateisystemreperaturen werden nur aufgrund des Journals durchgeführt.

[ingo2]

So, habe das heute nochmal erzwungen, indem ich mit tune2fs den Mount-Count hochgesetzt habe.
Da kommt dann raus:

Code: Alles auswählen

 journalctl | grep -a5 fsck
 
Feb 21 14:44:08 tux systemd-fsck[601]: /dev/sdb2 wurde 11-mal ohne Überprüfung eingehängt, Prüfung erzwungen.
Feb 21 14:44:08 tux systemd[1]: Starting Load/Save RF Kill Switch Status...
.....
Feb 21 14:44:10 tux systemd-fsck[601]: /dev/sdb2: 136915/60416000 Dateien (2.1% nicht zusammenhängend), 131397751/241662464 Blöcke
Feb 21 14:44:10 tux systemd[1]: Started File System Check on /dev/disk/by-uuid/6c19cd29-5d69-4f28-94a1-e6b938f4feaf.
Feb 21 14:44:10 tux systemd[1]: Mounting /home/ingo/data...
Feb 21 14:44:10 tux systemd[1]: Mounted /home/ingo/data.
Feb 21 14:44:10 tux systemd[1]: Reached target Local File Systems.
Feb 21 14:44:10 tux kernel: EXT4-fs (sdb2): mounted filesystem with ordered data mode. Opts: errors=remount-ro
--
....
Feb 21 14:44:40 tux systemd[1]: systemd-fsckd.service: Succeeded.

Und da sieht man, dass der Filesystem-Check in weniger als Sekunden erledigt ist und der eigentliche Check wohl < 1 sec. gedauert hat und die Partition gemountet wird.

Ich möchte aber den "ausführlichen Check" (wie früher) durchführen - geht wohl nicht mehr - Dank Systemd

[jph]

Und da sieht man, dass der Filesystem-Check in weniger als Sekunden erledigt ist und der eigentliche Check wohl < 1 sec. gedauert hat und die Partition gemountet wird.

Ich möchte aber den "ausführlichen Check" (wie früher) durchführen - geht wohl nicht mehr - Dank Systemd

Wie früher: du bist sicher, dass du nicht ext4 mit ext2 mit seinen nach fester Anzahl von Mounts oder Tagen erzwungenen Checks verwechselst? Dann konnte man Kaffee holen gehen.

[ingo2]

Wie früher: du bist sicher, dass du nicht ext4 mit ext2 mit seinen nach fester Anzahl von Mounts oder Tagen erzwungenen Checks verwechselst? Dann konnte man Kaffee holen gehen.

Das hat meines Wissens nichts mit ext2 (ohne Journal) zu tun. Ich bin sicher, dass ich mal ein NAS hatte (glaube QNAP) auf dem ich später Wheezy installiert habe. Und das hatte definitiv schon ext4. Da hat so ein fsck einer 750GB-Platte schon ca. 1 Stunde gedauert. Das sollte heute mit einer SSD ja wohl in ein paar Minuten erledigt sein - aber nicht in < 1sec. wie momentan.

Im Terminal wurden dann so etwa 5 - 6 verschiedene Teilprüfungen nacheinander reportet bis letztlich das ok kam.

Sagen wir mal so im übertragenen Sinne:
Im Moment prüft fsck nur die Bestandsliste auf Rechtschreibfehler. Ob die gelisteten Waren auch alle ordnungsgemäß vorhanen sind, leider nicht. Ich möchte aber ab und zu Inventur machen!

EDIT:
Ich hab' das hier gefunden https://www.thegeekstuff.com/2012/08/fs ... -examples/.
So war das füher, wenn man es via /forcefsck erzwungen hat:

# fsck /dev/sda6 -f
fsck from util-linux 2.20.1
e2fsck 1.42 (29-Nov-2011)
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
/dev/sda6: 95/2240224 files (7.4% non-contiguous), 3793503/4476416 blocks

[KP97]

Das funktioniert doch mit systemd immer noch wie vorher:

root@MB:~# fsck -f /dev/sda3
fsck from util-linux 2.34
e2fsck 1.45.5 (07-Jan-2020)
Durchgang 1: Inodes, Blöcke und Größen werden geprüft
Durchgang 2: Verzeichnisstruktur wird geprüft
Durchgang 3: Verzeichnisverknüpfungen werden geprüft
/lost+found nicht gefunden. Erstellen<jy>? ja
Durchgang 4: Referenzzähler werden überprüft
Durchgang 5: Zusammengefasste Gruppeninformation wird geprüft

Test: ***** DATEISYSTEM WURDE VERÄNDERT *****
Test: 114586/19202048 Dateien (0.3% nicht zusammenhängend), 2505489/76800000 Blöcke
root@MB:~#

Das zu prüfende Dateisystem muß natürlich ausgehängt sein.

[ingo2]

Hab's grad mal von meiner Service-Partition aus probiert (time fsck -f /dev/sdX) - Du hast Recht:

• sda2 1,2sec.
  sda3 0,8sec.
  sda5 1,2sec.
  sdb2 1,8sec.

Ist mir nur ein Rätsel, wie das in 2 Sekunden erledigt sein soll, was früher mit einer HD 1 Stunde gedauert hat? Wie gesagt, nur alle Inodes einlesen dauert fast 20s bei einer SATA-Speed von 500MB/s.

[ingo2]

So, jetzt verstehe ich das besser:

Wenn man sich diesen Graph https://en.wikipedia.org/wiki/File:E2fsck-uninit.svg mit dem Vergleich ext3/ext4 anschaut, sieht man deutlich, dass bei ext4 die Gesamtzahl der Inodes praktisch keinen Enfluß auf die Geschwindigkeit hat, während die bei ext3 unabhängig von der Zahl der Dateien ist und nur von der Gesamtzahl der Inodes eines Dateisystems abhängt. Es werden also bei ext4 gar nicht mehr alle Inodes eingelesen - wie ich aber angenommen hatte.

Es kommt also praktisch nur auf die Zahl der Dateien an.
Bei mir haben Systempartitionen so 250.000 - 350.000 Dateien, die Datenpartition 150.000 Dateien bei ca. 6Mio Inodes gesamt und knapp 1 TB.

Ob das bei ext4 jetzt ein Trade-off an Sicherheit zu Gunsten der Geschwindigkeit ist oder tatsächlich irrelevant, kann ich nicht beurteilen.

Ingo

[c1ue]

Code: Alles auswählen

tune2fs -l /dev/sdXY | grep checked

Ähm, gut, dass ich nochmal Deinen Beitrag gelesen habe:

tune2fs -l /dev/mapper/sda6_crypt | grep checked
Last checked: Mon Aug 3 10:22:41 2015

Das war original der Installationszeitpunkt meines Debians. Und dazwischen ist mein System beim Hochfahren bestimmt einige Hundertmal abgeschmiert.

[OrangeJuice]

Dann editiere doch in Grub optional mit Taste "E" beim Startvorgang fsck.mode=force usw. rein. Was für einen Datenträger verwendest du?

Code: Alles auswählen

GRUB_CMDLINE_LINUX_DEFAULT="fsck.mode=force fsck.repair=yes"

oder

Code: Alles auswählen

GRUB_CMDLINE_LINUX_DEFAULT="fsck.mode=force fsck.repair=preen"

[c1ue]

Dann editiere doch in Grub optional mit Taste "E" beim Startvorgang fsck.mode=force usw. rein. Was für einen Datenträger verwendest du?

Code: Alles auswählen

GRUB_CMDLINE_LINUX_DEFAULT="fsck.mode=force fsck.repair=yes"

oder

Code: Alles auswählen

GRUB_CMDLINE_LINUX_DEFAULT="fsck.mode=force fsck.repair=preen"

Moment, Moment. Ich will ja gerade nicht, dass er bei jedem Start das Dateisystem überprüft, sondern nur nach einem crash. Ich hab ne normale Festplatte.

[OrangeJuice]

Dann probier doch statt ein "force" einfach "auto" aus. Ich dachte mir, du solltest überhaupt mal sehen, ob es damit klappt. Du musst das ja nicht permanent setzten, sondern kannst es direkt in Grub vor dem Startvorgang eingeben, das wird dann nicht gespeichert und führt das nur einmal aus. Dann überprüfen ob fsck ausgeführt wurde.
Ich bin davon ausgegangen, dass es nicht geklappt hat.