Moje Ubuntu uruchamia fsck przy każdym uruchomieniu

Przy każdym uruchomieniu jest to samo:

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

Czy jest to jakaś opcja używana przez Ubuntu w celu zapewnienia spójności systemu plików, czy może coś jest nie tak z moim dyskiem twardym? fscktrwa do 30 sekund podczas uruchamiania, więc około trzykrotnie potrzeba czasu w przeciwnym razie.

Pełna wydajność (częściowo w języku niemieckim):

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: clean, 908443/38690816 Files, 44176803/154733312 Blocks

Linia generująca ten komunikat jest następująca :

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

Pomija „pełną kontrolę”, ale upewnił się, że niektóre szybkie testy dziennika są czyste i nie ma osieroconych i-węzłów:

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

Jest to normalne i oczekiwane. Gdyby to była naprawdę dokładna kontrola, zajęłoby to znacznie więcej czasu, ale zwykle zajmuje to sekundę lub mniej. Strona systemd-fsck(8)podręcznika systemowego zawiera warunki, w których uruchamiane jest pełne sprawdzenie:

systemd-fsck-root.service jest odpowiedzialny za kontrole systemu plików w głównym systemie plików, ale tylko jeśli główny system plików nie został sprawdzony w initramfs. systemd-fsck @ .service jest używany dla wszystkich innych systemów plików i dla głównego systemu plików w initramfs.

Usługi te są uruchamiane podczas rozruchu, jeśli passno w / etc / fstab dla systemu plików jest ustawione na wartość większą niż zero. Kontrola systemu plików dla roota jest przeprowadzana przed innymi systemami plików. Inne systemy plików mogą być sprawdzane równolegle, z wyjątkiem sytuacji, gdy znajdują się na tym samym dysku obrotowym.

systemd-fsck nie zna żadnych szczegółów na temat określonych systemów plików i po prostu wykonuje kontrole systemu plików specyficzne dla każdego typu systemu plików (/sbin/fsck.*). Ten pomocnik zdecyduje, czy system plików powinien zostać faktycznie sprawdzony na podstawie czasu od ostatniego sprawdzenia, liczby podłączeń, nieczystego odmontowania itp.

Możesz po prostu sprawdzić, czy testy zajęły prawie nic (jeśli używasz systemd):

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

Czy jesteś pewien, że fsck zajmuje 30 lat, a nie tylko to, że następny komunikat konsoli dotyczący udevd zajmuje 30 sekund? Innymi słowy, może udevd potrzebuje 30 sekund na przekroczenie limitu czasu pracy nad libticables przed wyświetleniem komunikatu konsoli?

Spróbuj usunąć (lub tymczasowo przenieść się w inne miejsce)

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

i zobacz, czy to pomoże.

Ten fsck przy każdym rozruchu przytrafił mi się z powodu złego zegara. Wygląda na to, że systemd-fsck @ działa przed systemd-timesyncd i bez RTC zasilanego bateryjnie czas systemowy jest nieprawidłowy w momencie uruchomienia fsck.

Potwierdziłem, że to rzeczywiście wyzwala pełne sprawdzenie (zamiast szybkiego wyjścia fsck), wyłączając systemd-timesynd, ustawiając zegar na wartość sprzed synchronizacji z dziennika i uruchamiając fsck. E2fsck przechodzi następnie do pełnego sprawdzenia, gdy tylko wykryje, że czas na ostatni superblok jest w przyszłości:

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
...

Zauważ, że ten wyzwalacz dla pełnego sprawdzenia nie jest związany z innymi wyzwalaczami maksymalnej liczby montowań i przedziału czasu od ostatniego sprawdzenia dumpe2fs -h, o którym mowa w innych odpowiedziach tutaj.

Zauważ, że bez ustawienia zegara (tj. Umożliwienia synchronizacji timesyncd), fsck nie wykona pełnego sprawdzenia, ale szybko zakończy działanie z komunikatem „wyczyść system plików”.

Aby obejść ten problem, wyłączyłem fsck w / etc / fstab, ustawiając pole „pass” na 0. W końcu kupię dla tego urządzenia baterię RTC.

Moje wyszukiwania doprowadziły mnie do wniosku, że domyślna maksymalna liczba zainstalowań Ubuntu jest ustawiona na -1. Oznacza to, że fsck nigdy nie uruchomi się na żadnym bootie, niezależnie od liczby montowań. Możesz sprawdzić swoją komendę -

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

Możesz go zwiększyć według własnego uznania, używając tune2fs. Typowy przykład jest następujący -

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

Dostosuj go według własnego uznania.