[gelöst]Maximum mount count -1 ?

Guten Abend miteinander,

mal eine Frage zwischendurch, d.h. überhaupt nicht dringend

Ich habe bisher immer geglaubt, daß der Eintrag heißt, daß das Gerät (Partition) beim nächsten Systemstart mit e2fsck automatisch überprüft werden wird. Ich bin mir jetzt nicht mehr sicher, ob das wirklich so ist. Oder direkt gefragt: was heißt das wirklich?

Überprüfe ich eine Partition mit so erhalte ich z.B. (auszugsweise) :
Das Filesystem ist demnach "clean", überprüft werden soll es wieder beim nächsten Systemstart (?), überprüft wurde es zuletzt am 16.April diesen Jahres. Starte ich den Rechner neu, so erhöht sich der Mount count um 1, alles ist wieder "clean" und überprüft wurde wieder zuletzt am 16.April des laufenden Jahres.

Diese Ausgabe ist zumindest für mich wirklich nicht sehr informativ. Vor allem weiß ich nicht, was mir diese Info sagen will. Was ist nun der Status?

Klar ist "clean" zumindest für den 16.April eindeutig. Aber bekomme ich den "Maxim mount count: -1" und die letzte tatsächliche Überprüfung nicht "unter einen Hut".

Ich würde mich freuen, bald auch dieses Geheimnis durchschauen zu können.

Gruss H.

das clean bedeutet das Dateisystem ist sauber ausgehängt worden, eigentlich bedeutet es, es wurde sauber gesynct und anschließend beim umounten die Filesystemmetadaten zurückgeschrieben. Ob das Dateisystem wirklich clean ist, ist damit nicht zwingend gemeint, aber der Kernel geht davon aus, da die Struktur des ext3/4 Filesystem eigentlich so sicher ist, das es sauber sein sollte, solange die Platte, kabel und der Kontroller nicht defekt ist und auch sonst keine größeren Bugs vorhanden sind.

der andere Status wäre mountet, diesen Status hat das Dateisystem dann auch wenn die Kiste zB abgestürzt war. In diesem Fall wird vor dem Mounten das Journal nach noch nicht erledigten Operationen durchsucht, diese nachgeholt und dann das Dateisystem auf clean gesetzt und gemountet. Es wird in diesem Fall nicht wie noch bei ext2 das gesamte Dateisystem auf alle möglichen Fehler überprüft, sonder nur das Journal abgearbeitet. Ein kompletter Filesystemcheck könnte bei großen Dateisystemen sehr lange, bei extrem großen und sehr vollen Dateisystenen auch Tage dauern. Und sind mehr als 1 solches Dateisystem dann zu überprüfen. würde das dann entsprechend ewig dauern bis der Rechner wieder bebootet hat. Nach dem abarbeiten des Journals ist auf dem Dateisystem eine stabile Situation vorhanden mit dem das Dateisystem gebootet werden kann auch wenn eventuell noch der eine oder andere kleine Fehler irgendwo im Dateisystem ist.

Weil jedoch per default nicht die gesamten Datenänderungen im Dateisystem durch das Journal abgesichert werden, sondern nur die wichtigen Metadaten des Dateisystems, könnte es theoretisch doch zu kleinen Fehlern im Dateisystem kommen. (zumindestens im Homebereich ist auch noch der Schreibcache auf den Festplatten eingeschalten, damit ist nicht immer gewährleistet das bei Stromausfall auch wirklich alles auf die Platte geschrieben wird, obwohl der Kernel eigentlich der Meinung ist, es ist geschrieben) Bei sehr häufigen Abstürzen im Homebereich sind einige Fehler durchaus zu erwarten, auch Bugs im Kernel oder den Dateisystemtreibern könnten kleinere Fehler erzeugen, die sich irgendwann mal potenzieren und dann zu Problemen führen könnten. Das clean Flag würde diese Fehler nicht kennen bzw berücksichtigen. Aus diesem Grund sollte bei einem ext3 oder ext4 auch ab und zu mal ein kompletter Dateisystemcheck gemacht werden, der solche kleinen Fehler dann finden und beseitigen würde.

Dafür gibt es 2 mögliche Einstellungen, entweder über die Anzahl der mounts oder über die Anzahl der Tage seit dem letztem Filesystemcheck. Was für deinen Rechner die richtige Einstellung ist, hängt sehr stark von der Nutzung ab.
Eine 0 oder eine -1 bei der Anzahl der Mounts schaltet die Option ab. es ist dann nur die Option der maximalen Tage aktiv, vorrausgesetzt sie steht nicht auch auf 0 oder -1

Ein paar mehr Infos gibts zB auch im Wiki

Bei einer einmaligen manuellen Reparatur, sollte man nicht gleich die Optionen ändern, soweit diese einigermaßen richtig eingestellt sind.
zB. Wenn man ein System hat mit überschaubarer kompletter fsckreparaturzeit, dann einfach die Datei "/forcefsck" anlegen.
und beim nächsten boot werden automatisch alle Dateisysteme gründlich überprüft und diese Datei wieder gelöscht.

robi

Wenn das datumsgesteuerte Überprüfen bei 12.3 nicht funktioniert, liegt es an der Eintragung in der Datei /etc/e2fsck.conf. Dann muß die Zeile entfernt bzw. zum Kommentar gemacht und danach die initrd (dort ist die Datei seit kurzem auch enthalten) neu erstellt werden.

josef-wien schrieb:

Bei 12.3 ist standardmäßig das datumsgesteuerte Überprüfen durch die Eintragung

Code:

broken_system_clock = 1

in der Datei /etc/e2fsck.conf de facto deaktiviert. Um es wieder zu aktivieren, muß die Zeile entfernt bzw. zum Kommentar gemacht und danach die initrd (dort ist die Datei seit kurzem auch enthalten) neu erstellt werden.

Zum Vergrößern anklicken....

Das sind eventuell aber auch nur die Nach- und Nebenwirkungen von solchen irrwitzigen Ideen wie systemd :zensur:
diese Option ist schon ein paar Jahre älter und eigentlich dazu da um auf nicht bateriegestützen CMos-Uhren aufmerksam zu machen, damit fsck nicht jedesmal prüft obwohl klar ist das die Systemzeit zu diesem Zeitpunkt nicht stimmen kann. Das passt natürlich genau in das Konzept von systemd, alles auf einmal anfangen egal welche Abhängikeiten bestehen, und alle Probleme die so unmöglich aufzulösen sind, löst man über die initrd. Solche Methoden haben nichts mit dem klassischem Linux zu tun, so wie ich es gelernt und auf meiner Hardware am laufen habe.

robi

robi schrieb:

Das sind eventuell aber auch nur die Nach- und Nebenwirkungen von solchen irrwitzigen Ideen wie systemd

Zum Vergrößern anklicken....

Auf das Wort "eventuell" kannst Du ruhig verzichten.

robi schrieb:

Solche Methoden haben nichts mit dem klassischem Linux zu tun

Zum Vergrößern anklicken....

Da muß ich Dir leider recht geben.

P. S. Ich habe meinen Text vor Deiner Antwort modifiziert, da mein 12.3 auch nicht mehr "von der Stange" ist und ich daher nie sicher sein kann, ob etwas bei einer 08/15-Installation ebenfalls so ist (systemd-bringt schließlich auch ein Binär-Programm systemd-fsck mit, in dem ich mit einem Hex-Editor auch den Aufruf von /sbin/fsck finde).

Danke Euch beiden für die wirklich umfassende Antwort. Dieses Forum hilft seinen Nutzern wo immer es möglich ist.

Schönen Sonntag noch - H.