sidadm
В операционных системах Linux создано большое количество файловых систем. Основным семейством исторически является ветка etx2/ext3/ext4 , но есть ещё много хороших вариантов. Например, xfs . Сегодня обсуждать отличия, плюсы и минусы файловых систем я не буду.
Компания SAP для своих продуктов, разворачиваемых на Linux, даёт собственные рекомендации по поводу использования файловых систем. Их можно найти, например, в SAP note 405827 — Linux: Recommended file systems.
Иногда на уровне файловой системы случаются сбои и возникают ошибки. Для проверки и устранения их в Linux используется универсальная утилита fsck . Она может быть использована для большинства видов файловых систем, так как на самом деле является лишь общим фронтендом для утилит проверки конкретных файловых систем, которые она ищет в системе. Например, fsck.ext3 . За подробностями добро пожаловать в man fsck .
В SUSE Linux Enterprise Server (по крайней мере, в версии 11 SP4) утилита создания файловых систем ( mkfs ) автоматически активирует в настройках файловых систем параметр «Maximum mount count». Для файловых систем etx2/ext3/ext4 текущие значения этого параметра можно просмотреть командой вида:
Дело в том, что файловая система в своём супер-блоке (super-block) хранит, в частности, счётчик количества монтирований (рис. 1).
В данном примере счётчик монтирований уже равен 21. И когда это значение достигнет параметра «Maximum mount count» (в данном примере это 37), операционная система автоматически при следующем старте выполнит принудительную проверку файловой системы утилитой fsck (рис. 2).
Если вы хотите, чтобы система автоматически проверяла файловые системы при каждом старте, то необходимо параметр «Maximum mount count» выставить в значение «1».
Есть ещё один момент в операционной системе — это файл /etc/fstab , который содержит записи монтирования файловых систем. Значение последнего шестого поля в записях в этом файле используется утилитой fsck при автоматической проверке во время старта операционной системы. Дело в том, что утилита, для ускорения тестирования использует параллелизм, а очередь тестирования файловых систем регулируется значением из шестого поля файла /etc/fstab. Если стоит «1», то файловая система проверяется в первую очередь. Такое значение устанавливается обычно для корневой файловой системы. Если значение равно «2», то проверка будет производится во вторую очередь (рис. 3).
 |
| Рис. 3. Пример содержимого файла /etc/fstab. |
Если выставить значение поля в «0», то проверка такой файловой системы проводиться не будет. Даже если сработает механизм тестирования по количеству монтирований, описанный выше.
В моей ситуации в SUSE Linux Enterprise Server в созданных файловых системах активировался данный механизм. Для больших файловых систем, на которых расположены файлы базы данных и SAP системы, я использовал механизм логических томов — LVM. Для уникальной идентификации файловых систем в Linux есть генератор UUID. Сгенерированный для каждой файловой системы UUID рекомендуется прописать в файле /etc/fstab вместо файлов-устройств. Таким образом, можно обезопасить себя от изменении имени файла-устройства файловой системы при рестарте сервера. Просмотреть UUID для файловых систем можно командой blkid .
Возвращаемся к авто-тестированию файловых систем.
При достижении счётчиком монтирований значения равного параметру «Maximum mount count» текущей файловой системы происходил запуск процедуры тестирования при следующем старте операционной системы. Мало того, что для больших файловых систем этот процесс далеко не быстрый, так еще и конкретно на моей конфигурации активация проверки для одной из файловых систем приводила к возникновению ошибки. Причём, ошибка была связана не с проверкой текущей файловой системы, а с конвертацией (resolve) UUID других файловых систем в файлы-устройств. В итоге старт операционной системы после проверки файловой системы останавливался в maintanance режиме, не смотря на успешность самой проверки (рис. 4).
 |
| Рис. 4. Ошибка при автоматической проверке файловой системы. |
Приходилось идти в консоль сервера и перезагружать его. После этого система стартовала в нормальном режиме.
В ошибке, я думаю, виновата LVM, которая на этапе проверки, возможно, не активирует все Volume Groups. Ошибку можно было бы как-то обойти. Но Виктор Ашик, к мнению которого в плане администрирования Linux я прислушиваюсь, не рекомендует использовать этот механизм принудительной проверки вовсе. Он в своих видео рассказывал истории из жизни, когда, посылая удалённый сервер, к консоли которого не было доступа, в перезагрузку, администраторы не могли дождаться его старта. И причиной была вышеописанная долгая проверка файловых систем при старте операционной системы. Так же он упоминал, что в RHEL данная функция отключена по умолчанию.
- скорректировать параметр «Maximum mount count» для всех файловых систем,
- выставить в шестом поле в записях в файле /etc/fstab значения в «0».
Я выбрал первый путь. Для того, чтобы отключить механизм автоматической проверки файловых систем по счётчику монтирований во время старта операционной системы достаточно установить параметр «Maximum mount count» в «-1». Сделать это можно командой вида:
 |
| Рис. 5. Установка параметра «Maximum mount count» в -1. |
 |
| Рис. 6. Проверка параметров файловой системы. |
Почему я не выбрал второй путь? Потому что значение «2» в шестом поле не отключает механизм авто-проверки файловой системы совсем, а оставляет активными ещё два механизма.
Первый состоит в следующем трюке. Если создать в корне операционной системы файл forcefsck , например, командой:
И перезагрузить операционную систему, то при старте будут проверены все файловые системы, у которых в /etc/fstab в шестом поле стоит «1» или «2». На этот случай я и не стал изменять записи в /etc/fstab .
А второй механизм — это проверка по прошествии временного интервала. В данном примере это 6 месяцев в параметре «Check interval» (рис. 1). В документации по tune2fs для журналируемых файловых систем не рекомендуется отключение обоих встроенных механизмов. Поэтому этот, второй, механизм я пока отключать не стал. Мне кажется, он более гибкий, чем счётчик количества монтирований. Так, в случае проверки файловой системы вручную, автоматом отодвигается принудительная проверка на указанный в параметре период.
Дополнительно можно заглянуть в хорошую статью на данную тему (на англ.).
Как отключить автоматически fsck в Linux
Если вы проверите файл /etc/fstab, вы найдете 6-е поле в качестве опции fsck. Например:
# cat /etc/fstab /dev/vg0/log_vol0 /some_dir ext3 defaults 1 2
То есть, если значение установлено равным нулю, устройство или раздел будут исключены из проверки fsck, и если оно не равно нулю, проверка fsck будет выполняться в том порядке, в котором установлено значение.
Корневой раздел будет иметь это значение равным единице, чтобы fsck сначала проверил его.
Зачем нужен автоматический fsck при загрузке
Не рекомендуется отключать проверку файловой системы.
Проверка файловой системы часто помогает снизить риск повреждения из-за неисправных дисков, кабелей, памяти или ошибок ядра, которые могут остаться незамеченными, пока они не вызовут потерю или повреждение данных.
Это не означает, что повреждение файловой системы будет происходить при нормальном завершении работы, но есть вероятность, что какое-то незамеченное событие может вызвать повреждение файловой системы, кроме системного сбоя.
Проверка файловой системы через регулярные промежутки времени необходима для поддержания работоспособности файловой системы.
ВНИМАНИЕ: Обычно не рекомендуется полностью выключать fsck.
Однако, если вы понимаете последствия и риски отключения автоматических проверок файловой системы и хотите продолжить, есть два способа отключить автоматические проверки:
Использование tune2fs (рекомендуется)
Чтобы настроить файловую систему, введите следующую команду.
Это делается автоматически во время установки для всех файловых систем ext, отформатированных установщиком Anaconda.
Это устанавливает максимальное число монтирования равным нулю, что означает, что rколичество раз монтирования файловой системы будет игнорироваться e2fsck и ядром.
Это также устанавливает интервал между проверками равным нулю, что полностью отключает зависящую от времени проверку.
Вы можете проверить текущие параметры и смонтировать значения счетчика / последнего значения fsck, выполнив следующую команду (показанную ниже с примером вывода):
# tune2fs -l /dev/ | egrep -i "mount count|Check interval|Last checked" Mount count: 10 Maximum mount count: 31 Last checked: Tue Nov 19 08:13:55 2013 Check interval: 15552000 (6 months)
Использование fstab
Кроме того, вы можете настроить шестое поле /etc/fstab на ноль, что отключает автоматическую проверку для этой файловой системы. (Ядро не знает об этих настройках и может все еще выводить уведомления во время монтирования, что файловая система не была проверена.)
Используя следующий пример для строки монтирования файловой системы:
# cat /etc/fstab /dev/vg0/log_vol0 /some_dir ext3 defaults 1 2
Обратите внимание на изменение в конце строки:
# cat /etc/fstab /dev/vg0/log_vol0 /some_dir ext3 defaults 1 0
Принудительно при следующей загрузке
Если вы принудительно отключили fsck, а затем вам нужно проверить свою файловую систему позже, вот как вы должны запустить fsck при следующей загрузке:
How to skip filesystem checks during boot
Whenever I shut down my Ubuntu 20.04 and reboot, I always get this message at the bottom of my screen:
Press Ctrl+C to cancel all filesystem checks in progress 
This process will take too long and press Ctrl + C does not have any effect. How to bypass it?
Are you shutting down the machine cleanly? A fsck should only occur after a configured number of boots (eg. 30) or a problem was detected last shutdown (eg. power outage or system forced off before shutdown completed)
@karel: I still don’t see an answer on that page, (except mine), that answers the question on this page. There is the link to the manpages that mentions fsck.mode, but the manpages do not spell out a solution that a new user can use. The Question is over four years old and refers to 16.04. This bug is specific to 20.04.
1 Answer 1
Removing Disk Check From 20.04 Boot
The command line option fsck.mode=skip can be used to skip the disk check when booting Ubuntu 20.04.
The line Checking disks: 0% complete may still come up but fsck will not be run, nor will boot time be increased.
Add fsck.mode=skip to the linux line in grub.cfg just before quiet splash
It is recommended to add the command to grub.cfg by editing /etc/default/grub thus: GRUB_CMDLINE_LINUX_DEFAULT=»fsck.mode=skip quiet splash» and then run sudo update-grub .
I have had this problem with a Live USB but not with an installed system.