1 жесткий диск с 4 файловыми системами EXT4, назовем их A(1,2,3,4), каждая из которых имеет запись в моем fstab, но монтируется очень редко, диск даже отключается через udiskctl во время инициализации.
1 жесткий диск, на котором размещено 8 файловых систем EXT4, каждая из которых имеет запись в моем fstab, 4 из них, скажем, B(1,2,3,4), автоматически монтируются во время инициализации, а четыре других, скажем, C(1,2,3,4), монтируются время от времени по требованию.
В этих условиях (A(1,2,3,4) не смонтирован и связанный с ним диск выключен; Ни одна из файловых систем C(1,2,3,4) не смонтирована) и по какой-либо причине (отказ питания, паника ядра, жесткий сброс…) система не выключается нормально.
При следующей перезагрузке каждая из этих файловых систем будет проверена.
Все файловые системы, которые не были смонтированы во время аварийного завершения работы, быстро очищаются:
В1:Сделан ли этот вывод на основе единственного прочтения суперблока?s_stateполе или проводятся другие проверки?
В2:Зависит ли это от причин, вызвавших аварийное отключение, от того, был ли включен основной диск или нет?
В3:Дадут ли эти проверки команду fsck смонтировать файловую систему?
Q4:Хотя эти чистые статусы отображаются на консоли, почему я не могу найти эти отчеты в журналах моего ядра (или других), в то время как трассировки для тех файловых систем, которые действительно нуждались в ремонте и в конечном итоге восстановлении, отображаются в журнале?
Под Linux-5.4 / e2fsck 1.46.5 /openrcкак система инициализации иметалогдействует как демон syslog, если это имеет значение.
Наиболее важные правила metalog:
Kernel messages :
facility = "kern"
logdir = "/var/log/kernel"
break=1
Fallback:
facility = "*"
minimum = 6
logdir = "/var/log/fallback"
решение1
Пожалуйста, не задавайте несколько вопросов.
При редактировании раздела mountкод файловой системы копирует таблицы распределения блоков раздела в память и помечает таблицы диска как «требующие восстановления».
Код файловой системы управляет распределением блоков со скоростью памяти, которая НАМНОГО быстрее скорости диска.
Периодически таблицы в памяти записываются обратно на диск, чтобы поддерживать их в относительно актуальном состоянии и избежать необходимости хранить их все в памяти одновременно.
При редактировании раздела umountтаблицы в памяти записываются на диск (снимая флаг «требуется восстановление»). Таблицы в памяти удаляются.
При сбое системы актуальные таблицы в памяти теряются, а на диске по-прежнему сохраняется флаг «требуется восстановление».
Если файловая система требуется для загрузки ( /etc/fstabзапись имеет значение auto), и на диске установлен флаг «требуется восстановление», fsckзапускается специфичный для файловой системы метод (например, fsck.ext4для ext4файловых систем), чтобы «восстановить» файловую систему — сделать таблицы распределения блоков «правильными» (минимизировать потери данных, убедиться, что никакие блоки не являются ни свободными, ни используемыми, ...), сохранить блоки, которые были записаны, пока «требуется восстановление», и т. д. Поскольку создает fsckсобственные таблицы, диск не может быть mountотредактирован, и, кроме того, на диске установлен флаг «требуется восстановление» до тех пор, пока fsckне будет выполнено успешно.
Эта предварительная fsckактивность системы, вызванная монтированием, происходит до того, как процесс загрузки достаточно «поднялся», чтобы действительно регистрировать сообщения, но попробуйте dmesg.
Спасибо, LustreOne,
Во время монтирования e2fsck проверит как флаг журнала «требуется восстановление», так и выполнит базовую проверку блоков суперблока и группового дескриптора, которые необходимы для монтирования файловой системы. Если установлено «требуется восстановление», то журнал будет воспроизведен повторно. Если будут найдены другие ошибки, то будет запущен полный e2fsck файловой системы. – LustreOne