Программа fsck: проверка и восстановление файловых систем. Как восстановить файловую систему в fsck

Иногда по разным причинам (в результате сбоя, некорректного завершения работы) файловые системы накапливают ошибки. Сами ошибки представляют собой «рассогласованные» структуры данных. Естественно, при возникновении такой ситуации необходимо как можно скорее привести повреждённую в порядок. С этой задачей отлично справляется утилита fsck . Она действительно очень эффективна и системные администраторы очень часто в первую очередь используют именно ее для восстановления или починки файловых систем.

Как работает fsck?

Утилита fsck (F ile S ystem Consistency Check ) изначально глубоко проверяла все структуры данных подряд, т. е. целиком всю файловую систему. Для поиска ошибок она задействовала методы эвристического анализа для ускорения и оптимизации процесса поиска ошибок. Однако, даже в этом случае для больших по объёму файловых систем эта процедура могла занимать много часов.

Позднее была реализована схема оценки состояния файловой системы, в основе которой лежит признак «чистого бита файловой системы». Если происходил сбой и файловая система (ФС) некорректно демонтировалась, то в суперблоке ФС устанавливался этот бит. По-умолчанию в Linux-системах на одном из этапов загрузки системы происходит проверка файловых систем, которые зарегистрированы в файлах /etc/fstab, /etc/vfstab, а также в /etc/filesystems. Таким образом, анализируя «чистый бит» ФС во время загрузки системы утилита определяет, стоит ли проводить проверку.

Журналируемые ФС в настоящее время позволяют утилите работать только с теми структурами данных, которым действительно необходима починка или восстановление. При необходимости fsck может восстановить всю ФС целиком благодаря всё тем же журналам ФС.

Некоторые особенности использования fsck в Linux

Для Linux-систем довольно часто (в особенности с использованием ФС ext) проверка ФС может быть организована таким образом, что она будет проводиться при прошествии некоторого числа демонтирований, даже если ФС полностью исправны. Это особенно актуально для настольных компьютеров, которые могут выключаться/включаться каждые сутки, перезагружаться в связи с особенностью их работы и применения, а также из-за свободного к ним доступа для подключения внешних устройств. В таких случаях проверка ФС (хоть и является полезной и благоприятной процедурой), оказывается слишком частой, а потому бессмысленной.

По-умолчанию в Linux проверка ФС проводится по прошествии 20 демонтирований. Для того, чтобы изменить количество демонтирований, после которых нужна проверка ФС нужно воспользоваться командой tune2fs :

$ sudo tune2fs -с 50 /dev/sda1 tune2fs 1.44.1 (24-Mar-2018) Setting maximal mount count to 50

Синтаксис и основные опции fsck

У команды fsck следующий синтаксис:

Fsck [параметр] -- [параметры ФС] [<файловая система> . . .]

Основные параметры:

Кроме основных опций для fsck существуют и специфические, зависящие от выполняемой задачи и/или ФС. Об этом более подробно можно прочитать в соответствующих страницах , используя команду man fsck . В содержании основного руководства для утилиты (в разделе «SEE ALSO») есть ссылки на другие страницы, например fstab(5), mkfs(8), fsck.ext2(8), fsck.ext3(8) и т. д. Информацию по этим ссылкам можно просматривать выполняя команду man с соответствующими параметрами, например man fsck.ext3.

В следующей таблице приводятся дополнительные (специальные), а также наиболее часто используемые опции, позволяющие использовать команду с максимальной гибкостью и эффективностью:

Примеры использования fsck

Для самой типичной ситуации, характерной для случаев, когда нужно восстановить (а точнее «починить») ФС, например на устройстве /dev/sdb2, следует воспользоваться командой:

$ sudo fsck -y /dev/sdb2

Здесь опция -y необходима, т. к. при её отсутствии придётся слишком часто давать подтверждение. Следующая команда позволит произвести принудительную проверку ФС, даже в том случае, если она исправна:

$ sudo fsck -fy /dev/sdb2

Одной из самых полезных является опция, позволяющая помечать повреждённые сектора и эта же опция используется чаще всего. Обычно такие ситуации (с повреждёнными секторами) возникают после сбоев, вызванных нештатным отключением электропитания:

$ sudo fsck -c /dev/sdb2

Работу файловыми системами нужно проводить, когда они отмонтированны от разделов. Однако, если возникает ситуация, когда нужно всё же произвести проверку на примонтированных ФС, то перед тем как использовать команду fsck с соответствующей опцией, нужно сначала перемонтировать нужную ФС в режиме «только для чтения»:

$ sudo mount remount,ro /dev/sdb2 $ sudo fsck -fy /dev/sdb2

Для указания, какую ФС использовать для раздела:

$ sudo fsck -t ext4 -y /dev/sdb2

Если fsck не справляется с исправлением/починкой ФС (что случается очень редко), то это может быть из-за повреждённого суперблока ФС. Его также можно восстановить, поскольку для суперблоков создаются их резервные копии. Но сначала нужно узнать, по каким адресам эти копии записывались, а затем попытаться восстановить суперблок из одной их резервных копий:

$ sudo fdisk -l $ sudo mkfs -t ext4 -n /dev/xvdb1 $ sudo fsck -b 163840 /dev/xvdb1

Команда -l упомянута в данном примере для наглядности того, что сначала нужно представлять, с каким устройством работать, т. к. она выводит список (в данном выводе опущен) доступных разделов. Команда mkfs предназначена для создания ФС, но с опцией -n её можно использовать для получения информации о ФС, в том числе и о расположении суперблоков. Следует следить за тем, чтобы ключом -t для mkfs задавалась соответствующая фактическому состоянию файловая система, в данном случае ext4.

Заключение

В данной статье мы рассмотрели работу и использование утилиты fsck. Как видно из статьи использование утилиты не предоставляет большой сложности. А возможности по проверки и восстановлению файловых систем в Linux у нее довольно большие, поэтому знание этой утилиты системному администратору просто необходимы.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter .

команда проверки файловой системы и интерактивного восстановления ее.

Синтаксис

Описание

Утилита fsck в первом варианте вызова проверяет набор стандартных файловых систем, либо систем указанных в параметрах. Для этого она использует стандартный скрипт размещенный по адресу /etc/rc выполняя автоматическую перезагрузку. Используя вызов getfsent утилита считывает дескриптор файловой системы (filesystem descriptor) с целью определить какие файловые системы нуждаются в проверке. Будут проверены разделы имеющие параметры "rw", "rq", "ro" и те которые имеют ненулевой параметр прохождения. Файловые системы имеющие параметр прохождения 1 (стандартная корневая файловая система) будет проверена один раз.

Сейчас fsck представляет собой оболочку вызывающую в случае необходимости другие утилиты из группы fsck_XXX . Сейчас доступны fsck_hfs , fsck_msdos , fsck_exfat и fsck_udf . Если утилита столкнется с серьезными нарушениями файловой системы или формат проверяемого раздела не будет соответствовать одному из выше перечисленных fsck завершится с ошибкой и автоматическая перезагрузка будет завершена с ошибкой. Для каждой исправленной системы будет выведена одна или несколько строк с информацией описывающей систему, место и характер коррекции.

Если будет получен сигнал QUIT, fsck завершит проверку системы и прекратит работу со статусом аварийного завершения. Это полезно если необходимо завершить проверку во время автоматической перезагрузке, но при этом не запускать многопользовательский режим.

Без параметра -p fsck проверяет и интерактивно восстанавливает несовместимые условия для файловых систем. Некоторые из данных действий по восстановлению могут привести к потери части данных. Объем потерь можно увидеть в диагностическом выводе. Если у пользователя нет прав на запись в файловой системе утилита автоматически будет выполнение с параметром -n.

Параметры

На операционных системах Mac OS X начиная c dthcbb 10.3 необходимость применения данной утилиты практически отсутствует. И с большинством проблем справляется дисковая утилита diskutil.

Если у вас все-таки такая необходимость возникла, перезагрузите компьютер в однопользовательский режим, зажав во время загрузки клавиши Cmd+S . Наберите в командной строке

/sbin/fsck -fy

После проверки дисков будет выведено либо

В некоторых ситуациях файлы сервера повреждаются, и тогда файловая система нуждается в восстановлении. Такое бывает, если VPS внезапно отключился или произошел какой-либо программный или аппаратный сбой.

Существуют методы восстановления файлов VPS; по крайней мере, вы можете спасти самые важные из них.

Важные замечания и риски

При любых обстоятельствах наилучшим способом защиты от потери данных является бэкап. Своевременное, регулярное и качественное резервное копирование – единственный способ обеспечить целостность важных данных.

Инструменты восстановления, такие как fsck, также часто полезны, но они не дают никаких гарантий успеха, и результат чаще всего зависит от удачи. Использование fsck может иногда приводить к повреждению данных на активных дисках. Описанная в этом руководстве процедура fsck работает с немонтированной файловой системой, чтобы минимизировать этот риск.

Примечание: При возможности настоятельно рекомендуется сделать снапшот сервера перед восстановлением с помощью fsck. Если во время процедуры данные будут утеряны, снапшот позволит повторить попытку или попробовать восстановить данные другими методами.

1: Восстановление с помощью ядра fsck

Примечание: Новые дистрибутивы (FreeBSD, CoreOS, Debian 8 и Ubuntu 15.04) не могут использовать ядро восстановления. Если вы пользуетесь одним из этих дистрибутивов, переходите к разделу «Восстановление с помощью ISO».

Первое, что нужно сделать, чтобы восстановить систему после повреждения, — смонтировать ядро восстановления, которое позволит запустить утилиту проверки файловой системы fsck. Это может помочь найти и исправить ошибки в файловой системе.

Запуск fsck

Сначала отключите сервер. Для этого введите в командную строку:

Также это можно сделать с помощью панели управления. Нажмите Power Off или аналогичный вариант.

Отключив сервер, перейдите в настройки и откройте раздел восстановления. Запишите, какое ядро использует сервер, чтобы вернуть все на места после восстановления. Затем смонтируйте ядро восстановления (кнопка Mount Recovery Kernel или подобная).

Изменив ядро, запустите сервер.

Затем подключитесь к серверу через консоль. На данный момент SSH-доступ к серверу, скорее всего, отсутствует, поскольку сервер использует ядро восстановления.

В текущем окне откроется сессия терминала, и вы получите доступ к среде Linux.

Теперь нужно запустить fsck, чтобы найти и исправить ошибки в файловой системе.

Способ вызова этой команды будет зависеть от того, поддерживает ли сервер VirtIO. Если да, то жесткий диск сервера, скорее всего — /dev/vda или /dev/vda1 (в зависимости от системы). Вы можете уточнить это, набрав:

Если сервер не поддерживает VirtIO, жесткий диск находится в /dev/sda.

Итак, вам нужно запустить команду:

fsck -yf /dev/vda

fsck -yf /dev/vda1

Утилита fsck запустится и попытается обнаружить ошибки. После этого можно снова отключить сервер.

Вернитесь в панель управления, откройте настройки и найдите параметры ядра. В выпадающем меню выберите ядро, которое использовалось ранее.

Проверка результатов

Изменив ядро, запустите сервер и подключитесь к нему через консоль.

Если сервер раньше не запускался, а теперь запустился – это хороший знак.

Если ранее отдельные команды предупреждали вас о возможном повреждении, попробуйте снова запустить эти операции, чтобы убедиться, что они выполняются без предупреждений.

Также важно проверить каталог /lost+found. В него fsck помещает частично восстановленные файлы.

Иногда fsck может восстановить данные файла, но не может найти ссылку на файл в файловой системе. По сути, это файл без имени. В такой ситуации fsck помещает файлы в каталог /lost+found, чтобы вы могли попытаться вручную определить, что это за файл.

Просмотрите содержимое каталога /lost+found:

cd /lost+found
ls

Если в каталоге есть файлы, откройте каждый из них и попробуйте понять, что это за файл. Часто сюда попадают удаленные файлы, которые использовались до сбоя системы.

Если повреждения файловой системы все еще ощутимы или загрузить сервер после перехода к стандартному ядру не удалось, попробуйте выполнить инструкции следующего раздела.

2: Восстановление с помощью ISO

Если ядро и fsck не помогли восстановить систему, попробуйте использовать ISO восстановления.

Обычно пользователи не могут самостоятельно монтировать ISO восстановления. Чтобы получить ISO, нужно обратиться за помощью к команде поддержки хостинг-провайдера.

Отключите сервер. Если у вас остался доступ к командной строке, введите:

Если доступа к командной строке нет, отключите сервер через панель управления.

Затем с помощью панели управления обратитесь за помощью в техподдержку. При этом следует перечислить предпринятые вами действия по восстановлению.

Команда техподдержки должна предоставить вам ISO для восстановления. После этого запустите сервер и подключитесь к нему через консоль.

Вы увидите главное меню среды восстановления.

Настройка сети в среде восстановления

Стандартный ISO восстановления, как правило, автоматически настраивает сетевое взаимодействие с серверами в регионах, которые поддерживают метаданные. В других регионах вам придется вводить данные сети вручную.

Используйте в настройке параметры общей сети.

Запуск fsck в ISO восстановления

Чтобы запустить проверку и восстановление файловой системы fsck, выберите в меню Check Filesystem (или аналогичный вариант) и нажмите Enter. Среда восстановления обнаружит образ диска и попытается запустить на нем fsck. Утилита сообщит о любых ошибках и проблемах, возникших на сервере.

Монтирование файловой системы и восстановление

Данная среда Linux запущена с образа ISO, а не с сервера, потому вам нужно смонтировать файловую систему в среде, чтобы получить доступ к файлам. Выберите в меню Mount your Disk Image и нажмите Enter. Образ диска будет обнаружен и смонтирован в /mnt в среде восстановления.

Если вы ранее запускали проверку файловой системы из ядра восстановления или из ISO-образа, теперь вы можете проверить наличие частично восстановленных файлов в каталоге /mnt/lost+found.

Перейдите в каталог /mnt, и вы увидите свою файловую систему:

cd /mnt
ls
bin/ etc/ lib/ media/ proc/ sbin/ sys/ var/
boot/ home/ lib64/ mnt/ root/ selinux/ tmp/ vmlinuz@
dev/ initrd.img@ lost+found/ opt/ run/ srv/ usr/

Откройте lost+found и просмотрите частично восстановленные файлы.

cd lost+found
ls

Если в этом каталоге есть файлы, восстановленные утилитой fsck, вы можете попытаться вернуть их на место и восстановить их в системе. Если это важные файлы, они могут помочь системе.

Если файлы в lost+found не поддаются восстановлению (или если вы хотите только сохранить некоторые данные), вы можете попытаться разгрузить свои файлы на удаленную машину (другой сервер или другую физическую машину).

Перемещение файлов с помощью SFTP

Если вы хотите переместить файлы на локальный компьютер, воспользуйтесь средой восстановления. Если вы находитесь в интерактивной оболочке, введите exit, чтобы вернуться в главное меню.

Убедитесь, что главное меню показывает смонтированную файловую систему, и включите SSH-сервер.

Будет предложено создать временный root пароль для доступа к серверу.

Примечание: Это никак не повлияет на постоянный root-пароль сервера.

Дважды введите временный пароль. После этого среда восстановления установит и настроит сервер SSH.

Теперь вы можете получить доступ к серверу с помощью клиента SSH или SFTP. SFTP-клиент Filezilla позволяет создавать новые соединения, требуя для этого следующие данные:

Host: your_ server_IP
Port: 22
Protocol: SFTP - SSH File Transfer Protocol
Login Type: Normal
User: root
Password: TEMPORARY_PASSWORD

После подключения вы попадёте в каталог /root. Файловая система будет в /mnt. Перейдите в этот каталог, выберите необходимые файлы и переместите их на локальную машину.

Файловая система UNIX на удивление надежна и выполняет значительную работу, справляясь с неожиданными сбоями системы и частыми отказами аппаратных средств. Тем не менее, существует ряд причин, вызывающих повреждение файловых систем и нарушение их целостности.

Каждый раз, когда ядро выдает сообщение о панике или отказывает система питания, в тех файловых системах, которые непосредственно перед сбоем находились в активном состоянии, происходят незначительные нарушения. Поскольку ядро хранит в памяти как блоки данных, так и управляющую информацию, то самый последний образ файловой системы распределяется между диском и памятью. Во время сбоя часть образа, находящаяся в памяти, пропадает. Хранящиеся в памяти блоки практически замещаются теми их версиями, которые были записаны на диск последними.

Имеются различные подходы к устранению этой проблемы. Небольшие повреждения обычно поддаются устранению с помощью команды fsck (сокращение от "filesystem consistency check" — проверка целостности файловой системы). С архитектурной точки зрения это не очень элегантный подход, но он себя оправдывает в большинстве распространенных ситуаций.

Файловые системы, в которых ведется журнал событий, записывают метаданные в последовательный журнальный файл, сохраняемый на диске перед завершением каждой команды. Впоследствии метаданные переносятся из журнального файла в соответствующее место файловой системы. Если происходит сбой системы, журнальный файл просматривается в обратном порядке и находится точка, когда система последний раз находилась в согласованном состоянии. Полная проверка файловой системы не требуется. Это очень полезно, если размер файловой системы очень велик.

Ведение журнала событий поддерживается в файловой системе UFS в Solaris и в файловой системе VXFS в HP-UX. Просмотрите описание процедуры инсталляции жесткого диска в HP-UX, где объясняется, как включить журнальный режим.

Если журнал событий не поддерживается, остается надеяться на программу fsck . Вот пять наиболее часто встречающихся видов повреждений:

наличие индексных дескрипторов, на которые нет ссылок;

неоправданно большие значения счетчиков ссылок;

неиспользуемые блоки данных, не отраженные в таблицах блоков;

блоки данных, указанные как свободные, но используемые в файле;

неверная статистическая информация в суперблоке.

Программа fsck устраняет все эти проблемы автоматически. Если программа делает изменения в файловой системе, ее нужно повторно выполнять до тех пор, пока файловая система не станет согласованной.

Диски обычно проверяются во время начальной загрузки с помощью команды fsck -р , которая исследует локальные файловые системы, перечисленные в файле fstab , и исправляет вышеуказанные пять ошибок. Новые операционные системы запоминают, какие файловые системы не были демонтированы корректно, и проверяют только их. Если ведется журнал событий, программа fsck сообщает о том, что поддерживается журнальный режим и восстанавливает последнее согласованное состояние системы на основании записей в журнальном файле.

Команду fsck -р можно выполнить и для отдельной файловой системы например:

# fsck -р /dev/rsd 0 g

Программа fsck обрабатывает файлы и блок-ориентированных, и байт-ориентированных устройств, но с последними она работает быстрее.

Когда программа fsck читает файл fstab , чтобы узнать, какие файловые системы проверять, она придерживается последовательности, обозначение, в последнем поле каждой записи. Файловые системы проверяются в порядке возрастания номеров. Если две файловые системы размещены на разны; дисках, им может быть присвоен один порядковый номер. Это заставит программу fsck проверить их одновременно; при этом минимизируется время затрачиваемое на ожидание дискового ввода-вывода. Первым всегда следует проверять корневой раздел.

Ошибки, не относящиеся ни к одной из пяти вышеуказанных категорий потенциально опасны. Они заставляют команду fsck -р вывести сообщение о помощи и завершить свою работу. В этом случае нужно запустить программ fsck без опции -р . При прогоне в ручном режиме программа просит подтверждения на каждую восстановительную операцию, которую собираете; выполнить. Вот некоторые ошибки, которые программа fsck считает опасными:

блоки, принадлежащие более чем одному файлу;

блоки, находящиеся вне диапазона файловой системы;

слишком маленькие счетчики ссылок;

неучтенные блоки;

различные ошибки формата файлов.

К сожалению, не имея глубоких знаний о структуре файловой системы восстановить диск вручную невозможно. Никогда не пробуйте производит» прямую запись в файловую систему через файлы устройств.

Во многих операционных системах имеется отладчик файловых систем (часто называемый fsdb ), который позволяет проверять и модифицировать данные на низком уровне, но для эффективного его использования нужно очень хорошо понимать, что он делает. Если ограничиться чтением файловой системы и не пытаться ее модифицировать, то можно избежать усугубления проблем.

На практике это означает, что выбор невелик и практически сводится к принятию условий, поставленных программой fsck . Проблемы можно свести к минимуму путем тщательной регистрации сообщений, выдаваемых программой, так как иногда они дают ответ на вопрос о том, какой файл (или файлы) является сбойным. Если программа запрашивает разрешение на удаление файла, попробуйте сначала скопировать его в другую файловую систему, а уж потом разрешайте программе продолжать работу. Но помните: каждый раз, пытаясь обратиться к поврежденной файловой системе, вы рискуете вызвать в ядре неразрешимую ошибку.

Если поврежденная файловая система содержит ценные данные, а программа fsck не смогла автоматически ее восстановить, не экспериментируйте с ней, не создав предварительно резервной копии. Можно попробовать применить к диску команду dump , но она предполагает наличие неповрежденной файловой системы, поэтому в результате могут быть потеряны данные (или команда завершится выдачей сообщения об ошибке). Лучше всего перестраховаться и выполнить для всего диска команду dd , чтобы создать резервный диск.

Если программа fsck знает только номер индексного дескриптора файла, то для выяснения его путевого имени в некоторых системах можно использовать команду ncheck . Для очистки дефектного индексного дескриптора, который программа fsck не может восстановить, можно воспользоваться командой clri (данные, естественно, будут потеряны).

Когда программа fsck обнаруживает файл, родительский каталог которого определить невозможно, она помещает такой файл в каталог lost+found , находящийся на верхнем уровне файловой системы. Поскольку имя, присвоенное файлу, регистрируется только в его родительском каталоге, имена файлов-сирот определить нельзя, и файлам, помещаемым в каталог lost+found , присваиваются имена, совпадающие с номерами их индексных дескрипторов.

Рано или поздно это случается, а именно крах системы или раздела, невозможность проверить файловую систему и т.д. Поэтому системный администратор должен знать что делать в таких ситуациях, так сказать знать как «Отче наш».

1) fsck при загрузке ОС

Когда случается сбой питания в работу вступает fsck: file system consistency check and interactive repair или если на русском, то «проверка целосности файловой системы и интерактивное восстановление» . По умолчанию проверка дисков отключена. Что бы её включить при загрузке системы, добавим такую строчку

fsck_y_enable="YES"

в файл /etc/rc.conf . В этом случае, при некорректном завершении работы сервера, будет автоматически запускаться проверка всех файловых систем.

Сама проверка состоит из 5-ти этапов:

** Phase 1 - Check Blocks and Sizes
** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
** Phase 5 - Check Cyl groups

На самом деле, Phase 1 ещё подразделяется на 1a и 1b . Это можно заметить только тогда, когда случился серъёзный крах.

Всё это хорошо, но есть одно НО! Когда происходит проверка файловой системы, то пока раздел не провериться, он не смонтируется и станет доступным, соответственно, увеличивается время загрузки сервера. Разработчики и это предусмотрели и сделали возможным запуск проверки в «фоне». Хотя на самом деле это только попытка, но всё же лучше, чем ничего. по умолчанию она включена. Правда по этому поводу точаться дискуссии на тему «нужно ли включать проверку в фоне или нет». Решать вам.

Есть один неприятный момент в процессе проверки ФС при загрузке. Если раздел достаточно большой, то его проверка может занять длительное время, при этом, fsck как бы зависает на каждом из этапов. Иными словами визуально непонятно, то ли идёт проверка, то ли сервер завис. Ну и при всём при этом непонятно, сколько уже проверено и сколько будет проверяться. Что бы немного облегчить жизнь системным администраторам, разработчики внедрили недокументированую возмножность. нажатие комбинации Ctrl+T показывает текущее состояние проверки: сколько уже проверено, в процентах. Если через пару минут захотите узнать опять состояние - нужно снова нажать Ctrl+T и так каждый раз.

Есть несколько параметров, которые прописываются в /etc/rc.conf и касаются fsck . Ниже приведены их дефолтные значения:

fsck_y_enable="NO" # Включить проверку при запуске, если работа была завершена некорректно.
fsck_y_flags="" # Дополнительные флаги для fsck -y
background_fsck="YES" # Попытка запустить проверку в фоне
background_fsck_delay="60" # Время задержки перед запуском fsck в фоне.

fsck_y_enable="YES"

И так, вот примеры работы fsck :

Если сервер выключался корректно, то при загрузке мы увидим такое сообщение:

Nov 10 14:36:33 mail kernel: Starting file system checks:
Nov 10 14:36:33 mail kernel: /dev/da0s1a: FILE SYSTEM CLEAN; SKIPPING CHECKS
Nov 10 14:36:33 mail kernel: /dev/da0s1a: clean, 942456 free (2944 frags, 117439 blocks, 0.3% fragmentation)
Nov 10 14:36:33 mail kernel: /dev/da0s1d: FILE SYSTEM CLEAN; SKIPPING CHECKS
Nov 10 14:36:33 mail kernel: /dev/da0s1d: clean, 503428 free (60 frags, 62921 blocks, 0.0% fragmentation)
Nov 10 14:36:33 mail kernel: /dev/da0s1e: FILE SYSTEM CLEAN; SKIPPING CHECKS
Nov 10 14:36:33 mail kernel: /dev/da0s1e: clean, 2301104 free (50872 frags, 281279 blocks, 1.0% fragmentation)
Nov 10 14:36:33 mail kernel: /dev/da0s1f: FILE SYSTEM CLEAN; SKIPPING CHECKS
Nov 10 14:36:33 mail kernel: /dev/da0s1f: clean, 162210122 free (2260506 frags, 19993702 blocks, 0.5% fragmentation)
Nov 10 14:36:33 mail kernel: Mounting local file systems:

Наличие ключевой фразы FILE SYSTEM CLEAN; SKIPPING CHECKS свидетельствует о предыдущем корректном завершении.

Если некорректно, то такое

Starting background file system checks in 60 seconds.
Jan 26 18:39:19 mail kernel: Starting file system checks:
Jan 26 18:39:19 mail kernel: /dev/da0s1a: 56013 files, 201857 used, 3349718 free (1702 frags, 418502 blocks, 0.0% fragmentation)
Jan 26 18:39:19 mail kernel: /dev/da0s1d: DEFER FOR BACKGROUND CHECKING
Jan 26 18:39:19 mail kernel: /dev/da0s1f: DEFER FOR BACKGROUND CHECKING
Jan 26 18:39:19 mail kernel: /dev/da0s1e: DEFER FOR BACKGROUND CHECKING

Но такое происходит не всегда. Если попытка не увенчалась успехом, то мы увидим такое:

** /dev/ad2s1g (NO WRITE)
** Last Mounted on /var
** Phase 1 - Check Blocks and Sizes

INCORRECT BLOCK COUNT I=446041 (4 should be 0)
CORRECT? yes
INCORRECT BLOCK COUNT I=446045 (4 should be 0)
CORRECT? yes

** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts

UNREF FILE I=89148 OWNER=root MODE=100600
SIZE=376 MTIME=Aug 13 13:49 2006
RECONNECT? yes
CLEAR? yes
UNREF FILE I=89152 OWNER=root MODE=100600
SIZE=755 MTIME=Aug 13 13:49 2006
RECONNECT? yes
CLEAR? yes

** Phase 5 - Check Cyl groups

FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? yes
SUMMARY INFORMATION BAD
SALVAGE? yes
BLK(S) MISSING IN BIT MAPS
SALVAGE? yes
2242 files, 1607116 used, 973436 free (2196 frags, 121405 blocks, 0.1% fragmentation)

2) Ручной запуск fsck

Сразу замечу, что проверка делается ТОЛЬКО НА НЕ СМОНТИРОВАННОМ РАЗДЕЛЕ! Иначе можете потерять все данные.
И так, рассмотрим только те параметры, которые часто используются. А именно

-y|-n : этот параметр будет отвечать соответственно YES|NO на все вопросы при возникновении несоответствий.
-B|-F : соответственно фоновый и нефоновый режимы
-f : проверить раздел, даже если он был отключён корректно.

fsck -y -f /dev/ad2s1g

Если запустить без параметра -y , то при проверке и нахождении несоответствий будет выдаваться вопрос, на что можно ответить Y или N . обычно отвечают Y . Не очень удобно каждый раз отвечать Y , поэтому лучше запускать с параметром Y

** /dev/ad2s1g (NO WRITE)
** Last Mounted on /var
** Phase 1 - Check Blocks and Sizes

INCORRECT BLOCK COUNT I=446041 (4 should be 0)
CORRECT?

Есть хорошая новость: комбинация CTRL+T работает и в ручном режиме.