[gelöst ] ungewollter fsck beim Systemstart

[Dampfmaschine]

Hallo zusammen.

Ich habe mir vor einigen Tagen Leap 42.3 installiert. Saubere Neuinstallation samt neu angelegtem Home-Verzeichnis.
Im Rechner sind mehrere Festplatten verbaut und entsprechend werden auch mehrere Partitionen beim Systemstart gemountet.
Das Problem ist nun, dass bei eigentlich jedem Systemstart ein automatischer fsck über 2 Partitionen läuft (1x 400GB und einmal knappe 8TB). Das muss ja nicht wirklich sein und nervt, weil es doch immer eine Weile dauert.
Beides sind ext4 Partitionen, beide sind sauber, wenn ich sie abhänge und fsck -f drüber laufen lasse.

Bei beiden steht laut tunes2fs -l

Maximum mount count:      -1

und

Check interval:           0 (<none>)

Demzufolge sollten sie doch eigentlich niemals automatisch geprüft werden?

Hat jemand eine Idee, was da falsch läuft?

 

[Sauerland]

Als root:

systemctl status systemd-fsck

jetzt nicht Enter Return drücken, sondern kurz hintereinander TAB und TAB.
Dann werden die möglichen Befehlserweiterungen angezeigt:
Beispiel:

linux64:~ # systemctl status systemd-fsck
systemd-fsck@dev-disk-by\x2duuid-1b216404\x2d48a6\x2d40c5\x2dbd62\x2d7e48ed4f60e9.service
systemd-fsck@dev-disk-by\x2duuid-a04c4eae\x2d6524\x2d4efc\x2dba13\x2dc249d684769e.service
systemd-fsck@dev-disk-by\x2duuid-c1b63225\x2dbd60\x2d4000\x2daae6\x2de276ecd17851.service
systemd-fsck-root.service
linux64:~ # systemctl status systemd-fsck

Es gibt also 4 mögliche Befehle.
Jetzt tippe ich den nächstmöglichen Buchstaben @ ein, drücke die TAB-Taste:

linux64:~ # systemctl status systemd-fsck@dev-disk-by\\x2duuid-

Noch einmal den nächsten Buchstaben, ich möchte den Status des Befehls der UID 1b216404\x2d48a6\x2d40c5\x2dbd62\x2d7e48ed4f60e9 mir anzeigen lassen:

systemctl status systemd-fsck@dev-disk-by\\x2duuid-1b216404\\x2d48a6\\x2d40c5\\x2dbd62\\x2d7e48ed4f60e9.service 
● systemd-fsck@dev-disk-by\x2duuid-1b216404\x2d48a6\x2d40c5\x2dbd62\x2d7e48ed4f60e9.service - File System Check on /dev/disk/by-uuid/1b216404-48a6-40c5-bd62-7e48ed4f60e9
   Loaded: loaded (/usr/lib/systemd/system/systemd-fsck@.service; static; vendor preset: disabled)
   Active: active (exited) since Do 2017-09-14 06:11:38 CEST; 9h ago
     Docs: man:systemd-fsck@.service(8)
  Process: 781 ExecStart=/usr/lib/systemd/systemd-fsck %f (code=exited, status=0/SUCCESS)
 Main PID: 781 (code=exited, status=0/SUCCESS)

Sep 14 06:11:38 linux64 systemd[1]: Starting File System Check on /dev/disk/by-uuid/1b216404-48a6-40c5-bd62-7e48ed4f60e9...
Sep 14 06:11:38 linux64 systemd-fsck[781]: /dev/sdb3: clean, 222320/57638912 files, 204551599/230554839 blocks
Sep 14 06:11:38 linux64 systemd[1]: Started File System Check on /dev/disk/by-uuid/1b216404-48a6-40c5-bd62-7e48ed4f60e9.

Vielleicht ist ja bei dir dort eine Fehlermeldung?

 

[Dampfmaschine]

Hallo Sauerland.

Erstmal Danke für die Antwort.
Das mit der Befehlserweiterung funktioniert so bei mir nicht, habe die entsprechenden Partitionen mit dem Gerätenamen in der fstab.
Heute komme ich wohl nicht mehr dazu, aber ich kann die in Yast ja problemlos wieder auf UUID umstellen und mir das dann anschauen.
Werde mich melden...
danke

 

[Sauerland]

Dann könnte dort

systemd-fsck@dev-disk-by-irgendwasanderes

stehen.
War nur ein Beispiel aus meiner Installation.

 

[Dampfmaschine]

Hätte natürlich gleich mehr Informationen liefern können, sorry, hab mir nix weiter bei gedacht.

:~ # cat /etc/fstab            
UUID=6af32f70-fe68-49a6-a9a4-392e14d9253b /                    ext4       acl,user_xattr        1 1
UUID=00d8194d-8c30-4cc1-8cb3-73b624a7f199 swap                 swap       defaults              0 0
/dev/sdc1                                 /data_1              ext4       defaults              1 2
/dev/sdb1                                 /data_2              ext4       defaults              1 2
UUID=b0614c75-85bf-45bb-a9be-e79610a2b492 /home                ext4       defaults              1 2
/dev/sdc6             /spiele_2            ntfs-3g    user,noauto,users,gid=users,fmask=133,dmask=022,locale=de_DE.UTF-8 0 0
/dev/sdc7            /tausch              vfat       users,gid=users,umask=0002,utf8=true 0 0

Du siehst, 4 mit Gerätenamen und 3 mit UUID
und da hier auch nur 3 angeboten werden, ging ich davon aus, dass dass eben die 3 mit UUID in der fstab sind.

:~ # systemctl status systemd-fsck
systemd-fsck-root.service
systemd-fsck@dev-disk-by\x2duuid-82e92be3\x2d9ece\x2d473b\x2d99e7\x2d76bf94bc8e91.service
systemd-fsck@dev-disk-by\x2duuid-8bb6eb91\x2d5545\x2d4fcb\x2db27a\x2d6e6d4e5ea960.service
systemd-fsck@dev-disk-by\x2duuid-b0614c75\x2d85bf\x2d45bb\x2da9be\x2de79610a2b492.service

edit: sehe gerade, dass ich Mist gedacht bzw geschrieben habe.
Die Mittlere ...uuid-8bb6eb91... ist eine der beiden.
/edit

Wie gesagt, schaue mir die Zuordnungen usw an und melde mich dann nochmal.
Hab jetzt keine Zeit mehr...
danke für die Mühe

 

[spoensche]

Als kurze Hintergrundinfo zu den UUID's:

Wie der Name UUID (Universal Unique Identifier) schon sagt handelt es sich bei einer UUID um einen Eindeutigen Identifizierer, in diesem Fall für Partitionen.

Der Job systemd-fsck ermittelt die zu prüfenden Partitionen bzw. Dateisystemen, weil er nur so eindeutig erkennen kann um welche Partition bzw. Dateisystem es sich handelt, ohne auf gerätespezifische Details angewiesen zu sein.

Die jeweilige Gerätedatei, z.B. /dev/sda, einer Festplatte o. Partition ist dynamisch und somit nicht eindeutig.

Was bedeutet in diesem Fall dynamisch?

Der Udev erzeugt beim Systemstart automatisch die entsprechenden Gerätedateien und dabei wird eine Reihenfolge berücksichtigt, wie z.B. SATA-Port 1 entspricht /dev/sda. Wenn sich dort etwas ändert, z.B. die Platte an Port 1 ist jetzt an Port 2 angeschlossen, dann ist die ehemalige 1. Festplatte nicht mehr /dev/sda, sondern /dev/sdb. Das hat u.U. zur Folge, dass in der fstab angebene Devices nicht mehr gemountet werden können, weil die Partition nicht existiert oder ein anderes Dateisystem verwendet.
Über die UUID ist sie allerdings jederzeit eindeutig identifzierbar, egal ob /dev/sda oder /dev/sdb.

Ungwollt sind die Dateisystemchecks trotzdem nicht. Beim Anlegen eines ext4 wird ein max. Mount Count etc. im Superblock hinterlegt. Wird der max. Wert erreicht, dann wird beim nächsten Systemstart automatisch ein Dateisystemcheck durchgeführt und der Counter auf 0 gesetzt. Diese Prozedur dient Datenkonsistenz und zur frühzeitigen Erkennung von defekten Inodes, die dann aus dem Journal wiederhergestellt werden können und somit Datenverlust vermieden wird.

 

[MH1962]

Ungwollt sind die Dateisystemchecks trotzdem nicht. Beim Anlegen eines ext4 wird ein max. Mount Count etc. im Superblock hinterlegt. Wird der max. Wert erreicht, dann wird beim nächsten Systemstart automatisch ein Dateisystemcheck durchgeführt und der Counter auf 0 gesetzt. Diese Prozedur dient Datenkonsistenz und zur frühzeitigen Erkennung von defekten Inodes, die dann aus dem Journal wiederhergestellt werden können und somit Datenverlust vermieden wird.

Der Maximal Mount Count steht doch aber beim Threadersteller grade auf -1, also auf "mach das nie". Was aber bei ext4 auch OK ist.

Es gibt ja zwei Verfahren: Einmal den Filesystem-Check, der hat aber den Nachteil, dass er seeeehr lange dauert und exklusiven Zugriff auf das Volume benötigt, also das System sehr lange zum Mounten des Volumes und damit meist auch zum Booten braucht.

Grade daher läuft es ja bei Journaling Filesystemen anders: Hier wird die Änderung nicht nur ins normale Filesystem geschrieben, sondern auch noch der alte Stand an eine besondere Stelle im Filesystem, nämlich das Journal gesichert. Passiert nun ein Absturz mitten während der Änderung, so ist das System beim nächsten Mounten in der Lage, unter Benutzung der Journal-Informationen sicherzustellen, dass die Änderung wieder vollständig rückgängig gemacht werden kann. Somit bleibt die Konsistenz des Filesystems immer gewahrt. Das ist eine sehr ähnliche Technik, wie sie bei Datenbanken verwendet wird.

Somit ist ein Filesystem-Check bei ext4 eigentlich nur noch bei Bedarf nötig und im Normalbetrieb unnötig und daher ist üblicherweise bei ext4 tatsächlich das Feature, ihn bei jedem Xten Mount zu machen, abgeschaltet.

 

[Dampfmaschine]

Hallo nochmal.

@MH1962: genau, ich mache das zwar gelegentlich mal manuell (so 2 -3 mal im Jahr, zur Sicherheit ob die Platten noch ok sind), aber beim booten stört es ungemein, gerade bei grösseren Platten.

@spoensche: ist natürlich alles richtig, aber in der Hinsicht weiss ich schon was ich mache und stöpsele nicht einfach wild die Laufwerke hin und her ;-)

Zur Sache selbst: keine Ahnung was das nun genau war, habe den Rechner eben 20x gestartet und ist sauber ohne fsck hochgefahren. Kann es mir eigentlich nur so erklären, dass er die letzten 2 Tage aus welchem Grund auch immer, nicht wirklich sauber runter gefahren ist und die Partitionen als dirty markiert waren.

Egal, hat sich erledigt.

Danke für eure Mühen

 

[josef-wien]

Die Aussage von MH1962 geht davon aus, daß das Dateisystem mit data=journal eingehängt ist. Standard ist immer noch data=ordered, hier kann es durchaus vorkommen, daß das Dateisystem Fehler enthält und eine regelmäßige Prüfung mit -f sinnvoll ist. Noch mehr trifft das auf data=writeback zu. (Siehe auch https://linux-club.de/wiki/opensuse/Bootverz%C3%B6gerungen_durch_fsck#Das_Filesystem-Journal, das gilt auch für Ext4.)