Моя Ubuntu запускает fsck при каждой загрузке

На каждой загрузке это то же самое:

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

Это какой-то вариант, который Ubuntu использует для обеспечения согласованности файловой системы, или что-то не так с моим жестким диском? fsckзанимает 30 секунд при загрузке и т. д. втрое больше времени, необходимого в противном случае.

Полный вывод (частично на немецком языке):

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

Строка, производящая это сообщение, выглядит так :

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

Он пропускает «полную проверку», но просто проверяет, что некоторые быстрые тесты в журнале чистые и нет инодевов-сирот:

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

Это нормально и ожидаемо. Если бы это была действительно тщательная проверка, это заняло бы намного больше времени, но обычно это занимает секунду или меньше. systemd-fsck(8)Страница справочника Systemd имеет условия, при которых запускается полная проверка:

systemd-fsck-root.service отвечает за проверки файловой системы в корневой файловой системе, но только если корневая файловая система не была проверена в initramfs. systemd-fsck @ .service используется для всех других файловых систем и для корневой файловой системы в initramfs.

Эти службы запускаются при загрузке, если для passno в / etc / fstab для файловой системы установлено значение больше нуля. Проверка файловой системы на наличие root выполняется перед другими файловыми системами. Другие файловые системы могут проверяться параллельно, кроме случаев, когда они находятся на одном вращающемся диске.

systemd-fsck не знает никаких подробностей о конкретных файловых системах и просто выполняет проверки файловой системы, специфичные для каждого типа файловой системы (/sbin/fsck.*). Этот помощник решит, следует ли проверять файловую систему на основе времени, прошедшего с момента последней проверки, количества монтирований, нечистого демонтирования и т. Д.

Вы можете просто проверить, что тесты практически не выполнялись (если вы используете 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

Вы уверены, что fsck берет 30 секунд, а не только то, что следующее консольное сообщение, касающееся udevd, занимает 30 секунд? Другими словами, может быть, udevd тратит 30 секунд на тайм-аут работы над libticables, прежде чем показывать консольное сообщение?

Попробуйте удалить (или временно переместить в другое место)

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

и посмотрим, поможет ли это.

Этот fsck на каждой загрузке случался со мной из-за плохих часов. Похоже, что systemd-fsck @ запускается до systemd-timesyncd, и без RTC с резервным питанием от батареи системное время неверно во время запуска fsck.

Я подтвердил, что это действительно то, что запускает полную проверку (вместо быстрого выхода из fsck), отключив systemd-timesynd, установив в clock значение предварительной синхронизации, найденное в journalctl, и запустив fsck. Затем e2fsck выполняет полную проверку, как только обнаруживает, что время последней записи суперблока находится в будущем:

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

Обратите внимание, что этот триггер для полной проверки не связан с другими триггерами максимального количества монтирования и временного интервала с момента последней проверки dumpe2fs -h, о которой говорилось выше, упомянутой в других ответах здесь.

Обратите внимание, что без установки часов (то есть синхронизации timeyncd) fsck не выполнит полную проверку, но быстро завершит работу с сообщением «очистка файловой системы».

В качестве обходного пути я отключил fsck в / etc / fstab, установив для поля 'pass' значение 0. В конце концов, я куплю RTC с батарейным питанием для этого устройства.

Мои поиски заставляют меня заключить, что максимальное количество монтирования Ubuntu по умолчанию установлено равным -1. Это означает, что fsck никогда не запустится ни при какой загрузке, независимо от количества монтирований. Вы можете проверить свои по команде -

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

Вы можете увеличить его по вашему требованию, используя tune2fs. Типичный пример выглядит следующим образом -

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

Настройте его по своему усмотрению.