Mein Ubuntu führt bei jedem Booten fsck aus

Bei jedem Booten ist es dasselbe:

/dev/sda1: clean, 908443/38690816 files, 44176803/154733312 blocks

Ist es eine Option, die Ubuntu verwendet, um die Konsistenz des Dateisystems zu gewährleisten, oder stimmt etwas mit meiner Festplatte nicht? fsckdauert beim Booten bis zu 30s und verdreifacht die sonst benötigte Zeit.

Volle Ausgabe:

Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... done.
Begin: Running /scripts/local-bottom ... done.
done.
Begin: Running /scripts/init-bottom ... done.
fsck von util-linux 2.20.1
/dev/sda1: sauber, 908443/38690816 Dateien, 44176803/154733312 Blöcke
udevd[623]: unknown key 'SYSFS{idVendor}' in /lib/udev/rules.d/45-libticables.rules:6

udevd[623]: invalid rule '/lib/udev/rules.d/45-libticables.rules:6'

 * Starting mDNS/DNS-SD daemon                                                 [ OK ]
 * Starting Reload cups, upon starting avahi-daemon to make sure remote queues are populated                                                                   [ OK ]
 * Starting configure network device security                                  [ OK ]
 * Starting bluetooth daemon                                                   [ OK ]
 ####* Starting all other stuff

/ dev / sda1: sauber, 908443/38690816 Dateien, 44176803/154733312 Blöcke

Die Linie , die Nachricht Herstellung ist dies :

/* Print the summary message when we're skipping a full check */
log_out(ctx, _("%s: clean, %u/%u files, %llu/%llu blocks"),

Es überspringt die "vollständige Prüfung", stellt jedoch nur sicher, dass einige schnelle Tests im Journal fehlerfrei sind und keine verwaisten Inodes vorhanden sind:

cat /var/log/boot.log 
fsck from util-linux 2.20.1
fsck from util-linux 2.20.1
/dev/sda1: clean, 260598/771552 files, 1684682/3080192 blocks
/dev/sdb10: recovering journal
/dev/sdb10: Clearing orphaned inode 142568 (uid=1000, gid=1000, mode=0100664, size=32768)
/dev/sdb10: Clearing orphaned inode 138527 (uid=1000, gid=1000, mode=0100600, size=9580)
/dev/sdb10: clean, 54957/991232 files, 3498365/3958006 blocks

Das ist normal und wird erwartet. Wenn es eine gründliche Prüfung wäre, würde es viel mehr Zeit in Anspruch nehmen, aber normalerweise dauert es eine Sekunde oder weniger. Die systemd-fsck(8)Handbuchseite von Systemd enthält die Bedingungen, unter denen eine vollständige Überprüfung ausgelöst wird:

systemd-fsck-root.service ist für die Dateisystemüberprüfung im Root-Dateisystem verantwortlich, jedoch nur, wenn das Root-Dateisystem im initramfs nicht überprüft wurde. systemd-fsck @ .service wird für alle anderen Dateisysteme und für das Root-Dateisystem im initramfs verwendet.

Diese Dienste werden beim Booten gestartet, wenn passno in / etc / fstab für das Dateisystem auf einen Wert größer als Null gesetzt ist. Die Dateisystemprüfung für root wird vor den anderen Dateisystemen durchgeführt. Andere Dateisysteme können parallel überprüft werden, es sei denn, sie befinden sich auf derselben rotierenden Platte.

systemd-fsck kennt keine Details zu bestimmten Dateisystemen und führt einfach Dateisystemprüfprogramme aus, die für jeden Dateisystemtyp spezifisch sind (/sbin/fsck.*). Dieser Helfer entscheidet, ob das Dateisystem tatsächlich geprüft werden soll, basierend auf der Zeit seit der letzten Prüfung, der Anzahl der Ladevorgänge, dem unreinen Ladevorgang usw.

Sie können einfach überprüfen, ob die Tests so gut wie nichts ausgeführt haben (wenn Sie systemd verwenden):

sudo systemd-analyze blame | grep fsck
          1.608s systemd-fsck@dev-disk-by\x2duuid-408535fe\x2d28e6\x2d4d82\x2dbb59\x2d9810ead089a3.service
            87ms systemd-fsck@dev-mapper-vlhome\x2dlvhome.service

Sind Sie sicher, dass es fsck ist, das 30s dauert und nicht nur, dass die nächste Konsolenmeldung in Bezug auf udevd 30 Sekunden dauert? Mit anderen Worten, vielleicht dauert es beim udevd 30 Sekunden, bis eine Zeitüberschreitung bei der Bearbeitung der libticables-Sache eintritt, bevor eine Konsolenmeldung angezeigt wird?

Versuchen Sie, das Gerät zu entfernen (oder vorübergehend an einen anderen Ort zu verschieben).

/lib/udev/rules.d/45-libticables.rules

und sehen, ob das hilft.

Dieser fsck bei jedem boot ist mir wegen schlechter uhr passiert. Es scheint, dass systemd-fsck @ vor systemd-timesyncd ausgeführt wird. Ohne batteriegepufferte Echtzeituhr ist die Systemzeit zum Zeitpunkt der Ausführung von fsck falsch.

Ich habe bestätigt, dass dies in der Tat der Auslöser für die vollständige Überprüfung ist (anstatt dass fsck schnell beendet wird), indem ich systemd-timesynd deaktiviere, die Uhr auf den in journalctl gefundenen Wert vor der Synchronisierung einstelle und fsck ausführe. Das e2fsck führt dann eine vollständige Prüfung durch, sobald es feststellt, dass die letzte Superblock-Schreibzeit in der Zukunft liegt:

fsck from util-linux 2.29.2
e2fsck 1.43.4 (31-Jan-2017)
Superblock last write time (Mon Jun 19 00:48:11 2017,
    now = Tue Jan 31 20:09:28 2017) is in the future.
Fix<y>? yes
Pass 1: Checking inodes, blocks, and sizes
...

Beachten Sie, dass dieser Auslöser für die vollständige Prüfung nichts mit den anderen Auslösern für die maximale Anzahl von Ladevorgängen und das Zeitintervall seit der letzten Prüfung zu tun hat, wie dumpe2fs -hin den anderen Antworten hier erwähnt.

Beachten Sie, dass fsck keine vollständige Überprüfung durchführt, ohne die Uhr einzustellen (dh zuzulassen, dass timesyncd sie synchronisiert), sondern schnell mit der Meldung "Dateisystem bereinigt" beendet wird.

Um dieses Problem zu umgehen, habe ich fsck in / etc / fstab deaktiviert, indem ich das Feld 'pass' auf 0 gesetzt habe. Schließlich werde ich eine batteriegepufferte Echtzeituhr für dieses Gerät kaufen.

Meine Suchanfragen lassen den Schluss zu, dass Ubuntu standardmäßig die maximale Anzahl der Ladevorgänge auf -1 setzt. Dies bedeutet, dass fsck unabhängig von der Anzahl der Mounts niemals auf einem Boot ausgeführt wird. Sie können Ihre per Befehl überprüfen -

sudo dumpe2fs -h /dev/sda8 | grep -i 'mount count'

Sie können es bei Bedarf mit erhöhen tune2fs. Ein typisches Beispiel ist wie folgt:

sudo tune2fs -c 30 -i 1w /dev/sda8

Passen Sie es nach Ihren Wünschen an.