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

19

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

/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
s3lph
источник
Какую версию Ubuntu вы используете? Ваша система выключается чисто?
ubfan1
Raring x64 = 13,04 64бит. Выключение проходит, насколько я могу сказать, чисто (Где находится файл журнала выключения?)
s3lph
1
fsck говорит, что он не работал, что том был чистым.
Псуси
Но проверяющий компонент должен работать, чтобы сказать, что он чистый, не так ли?
s3lph

Ответы:

25

/ 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
Braiam
источник
Ответ на вопрос по вашей ссылке говорит, что вы можете контролировать поведение, изменяя /etc/fstab. Можно ли только установить 0или 1я могу сообщить своей системе, когда выполнять этот «быстрый» тест?
s3lph
@ the_Seppi нет, вы не можете деактивировать fsck в fstab, но порядок, этот другой мой ответ объясняет это, просто прочитайте его до конца.
Брайам
Я прочитал, что изменение последней цифры на 0 отключает fsck при монтировании
s3lph
@the_Seppi да, вы правы 1и 2определяете порядок проверки, но 0никто не говорит, что в этом нет необходимости. Но тогда у меня есть оба значения в 0 и все еще получить чек.
Брайам
2
На панели запуска сообщается об ошибке : upstart bug # 1504688 . Это содержит возможное решение в комментарии № 17 .
Азуркин
1

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

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

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

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

Джозеф Сантаниелло
источник
Нет, это точно fsck. Running /scripts/init-bottom ...doneПечатаются около 3 секунд, то Fsck-чистого примерно 30 - х лет.
s3lph
Какой тип файловой системы вы используете?
Джозеф Сантаниелло
Я использую EXT4
s3lph
Пауза перед выводом "fsck von ..." или перед "/ dev / sda ..."?
Джозеф Сантаниелло
Где вы монтируете / dev / sda1? Вы можете попробовать добавить: noauto,x-systemd.automountк опциям fstab, если это / home или что-то еще. Таким образом, система будет пропускать монтирование до тех пор, пока к ней не будет произведен доступ в соответствии с: wiki.archlinux.org/index.php/Systemd#Automount
Джозеф Сантаниелло,
0

Этот 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 с батарейным питанием для этого устройства.

алексей
источник
-1

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

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

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

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

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

Вивек Джи
источник
1
Нет, это означает, что это значение не будет приниматься ядром и e2fsck: linux.die.net/man/8/tune2fs "Если max-mount-counts равен 0 или -1, то количество раз монтирование файловой системы будет игнорироваться e2fsck (8) и ядром. "
HappyCactus
Мой плохой, изменит пост.
Вивек Цзи