В операционных системах 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 текущие значения этого параметра можно просмотреть командой вида:
tune2fs -l /dev/device_file
Дело в том, что файловая система в своём супер-блоке (super-block) хранит, в частности, счётчик количества монтирований (рис. 1).
 |
| Рис. 1. Пример вывода настроек файловой системы. |
В данном примере счётчик монтирований уже равен 21. И когда это значение достигнет параметра "Maximum mount count" (в данном примере это 37), операционная система автоматически при следующем старте выполнит принудительную проверку файловой системы утилитой fsck (рис. 2).
 |
| Рис. 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).
В моей ситуации в 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" в "-1". Сделать это можно командой вида:
Почему я не выбрал второй путь? Потому что значение "2" в шестом поле не отключает механизм авто-проверки файловой системы совсем, а оставляет активными ещё два механизма.
Первый состоит в следующем трюке. Если создать в корне операционной системы файл forcefsck, например, командой:
А второй механизм - это проверка по прошествии временного интервала. В данном примере это 6 месяцев в параметре "Check interval" (рис. 1). В документации по tune2fs для журналируемых файловых систем не рекомендуется отключение обоих встроенных механизмов. Поэтому этот, второй, механизм я пока отключать не стал. Мне кажется, он более гибкий, чем счётчик количества монтирований. Так, в случае проверки файловой системы вручную, автоматом отодвигается принудительная проверка на указанный в параметре период.
Дополнительно можно заглянуть в хорошую статью на данную тему (на англ.).
P.S. Успейте поучаствовать в голосовании про ваш уровень английского языка, если ещё не оставили свой голос. Спасибо.
В ошибке, я думаю, виновата LVM, которая на этапе проверки, возможно, не активирует все Volume Groups. Ошибку можно было бы как-то обойти. Но Виктор Ашик, к мнению которого в плане администрирования Linux я прислушиваюсь, не рекомендует использовать этот механизм принудительной проверки вовсе. Он в своих видео рассказывал истории из жизни, когда, посылая удалённый сервер, к консоли которого не было доступа, в перезагрузку, администраторы не могли дождаться его старта. И причиной была вышеописанная долгая проверка файловых систем при старте операционной системы. Так же он упоминал, что в RHEL данная функция отключена по умолчанию.
Я решил отключить проверку и на данных серверах. Как вы поняли из описания механизма, решения у этой задачи может быть два:
- скорректировать параметр "Maximum mount count" для всех файловых систем,
- выставить в шестом поле в записях в файле /etc/fstab значения в "0".
Я выбрал первый путь. Для того, чтобы отключить механизм автоматической проверки файловых систем по счётчику монтирований во время старта операционной системы достаточно установить параметр "Maximum mount count" в "-1". Сделать это можно командой вида:
tune2fs -с -1 /dev/device_file
После этого для этой файловой системы механизм будет деактивирован (рис. 5 и 6).
 |
| Рис. 5. Установка параметра "Maximum mount count" в -1. |
 |
| Рис. 6. Проверка параметров файловой системы. |
Почему я не выбрал второй путь? Потому что значение "2" в шестом поле не отключает механизм авто-проверки файловой системы совсем, а оставляет активными ещё два механизма.
Первый состоит в следующем трюке. Если создать в корне операционной системы файл forcefsck, например, командой:
touch /forcefsckИ перезагрузить операционную систему, то при старте будут проверены все файловые системы, у которых в /etc/fstab в шестом поле стоит "1" или "2". На этот случай я и не стал изменять записи в /etc/fstab.
А второй механизм - это проверка по прошествии временного интервала. В данном примере это 6 месяцев в параметре "Check interval" (рис. 1). В документации по tune2fs для журналируемых файловых систем не рекомендуется отключение обоих встроенных механизмов. Поэтому этот, второй, механизм я пока отключать не стал. Мне кажется, он более гибкий, чем счётчик количества монтирований. Так, в случае проверки файловой системы вручную, автоматом отодвигается принудительная проверка на указанный в параметре период.
Дополнительно можно заглянуть в хорошую статью на данную тему (на англ.).
P.S. Успейте поучаствовать в голосовании про ваш уровень английского языка, если ещё не оставили свой голос. Спасибо.
Автор: Шиболов Вячеслав Анатольевич
Комментариев нет:
Отправить комментарий