Freebsd fsck проверка диска
1. Загружаемся в Single User Mode(Одно пользовательский режим) или используем Rescue-CD диск.
2. Отмонтируем файловую систему.
y — отвечать yes на все вопросы (альтернатива: ключ p — запускает проверку в полностью автоматическом режиме);
f — принудительная проверка (проводится даже если файловая система помечена как работоспособная);
c — искать битые блоки (bad blocks) и помечать их соответствующим образом;
/dev/sda1 — устройство и раздел, которые следует проверять (в данном случае, указан первый раздел первого диска).
v – verbose, будет выводить детальную информацию на терминал
Если есть вопросы, то просим Вас посетить наш форум, на котором Вы сможете попросить бесплатно описание.
Выводы
Вот и все, теперь вы знаете как выполняется восстановление файловой системы ext4 или любой другой, поддерживаемой в linux fsck. Если у вас остались вопросы, спрашивайте в комментариях!
На десерт сегодня видео на английском про различия файловых систем ext4 и xfs, как обычно, есть титры:
Одно из самых важных устройств компьютера - это жесткий диск, именно на нём хранится операционная система и вся ваша информация. Единица хранения информации на жестком диске - сектор или блок. Это одна ячейка в которую записывается определённое количество информации, обычно это 512 или 1024 байт.
Битые сектора, это повреждённые ячейки, которые больше не работают по каким либо причинам. Но файловая система всё ещё может пытаться записать в них данные. Прочитать данные из таких секторов очень сложно, поэтому вы можете их потерять. Новые диски SSD уже не подвержены этой проблеме, потому что там существует специальный контроллер, следящий за работоспособностью ячеек и перемещающий данные из нерабочих в рабочие. Однако традиционные жесткие диски используются всё ещё очень часто. В этой статье мы рассмотрим как проверить диск на битые секторы Linux.
Установка файловой системы
Вы можете указать какую файловую систему нужно проверять на разделе, например:
sudo fsck -t ext4 /dev/sdb1
FreeBSD 11: Проверка состояния SMART жёстких дисков
Проверка SMART жёсткого диска — важная операция, которую надо проводить время от времени. Если в Windows это можно просто сделать с помощью россыпи программ с графическим интерфейсом, то во FreeBSD (если нет GUI) сделать это немного сложнее. Но мы справимся!
- Для начала установим всё необходимое из портов. Переходим в
- Устанавливаем
- Получаем список дисков и разделов
На выходе получим что-то такое
Первая строка — это сам HDD, остальные это разделы на нём. В данном случае у нас один SATA HDD с тремя разделами на нём.
А дальше подставляем название HDD в команду, которой мы можем воспользоваться благодаря установленному порту
Появляется довольно обширная информация по состоянию выбранного HDD. В этом конкретном случаем HDD больше не пригоден для использования, так как у атрибута Reallocated_Sector статус FAILING_NOW. Беда!
Оцените статью:
Об авторе
13 комментариев
Для любителей гуя есть gsmartcontrol
Какие нахрен битые сектора. в каком веке живете? Или вы про Self тест?
А в каком веке перестали сыпаться ХДД?
Если ты настолько туп что не понимаешь что такое бэд блоки, то какого хрена ты вообще тут пишешь
Ты будешь очень удивлен, когда узнаешь, что битые сектора еще на стадии производства жестких дисков появляются. Причина этого: несовершенство технологии производство, как бы не парадоксально это звучало. По этой же причине с одной матрицы, на которой выращивают процессора получают как сверхвысокопроизводительные процессора с высокой стоимостью, так и самые дешевые целерончики. Так вот, те битые сектора, которые определяют еще на производстве помечают и заносят в специальный список. который хранится, в зависимости от производителя харда или в специальном разделе, или во флешпамяти или там и там. Наличие заводских бэдов подтверждает график чтения диска. Его можно увидеть прогнав новый диск (из заводской упаковки) какой нибудь утилитой типа Виктории или МХДД. Провалы в графике чтения, который представляет собой логарифмическую кривую это и есть подтверждение наличия заводских сбойных секторов: то есть на этих областях головка харда переходит по указанному адресу. То есть там алгоритм такой: головка доходит до нужного адреса на диске: считывает с него инфу, и если видит что-то подобное: этот блок сбойный, если вы хотите что-то записать, то вместо него работает вооон тот блок, расположенный воооон там.
э
Уважаемый автор, что-то я не понял про "просто" fsck. У него параметром "-l" не подставляется файл от "badblocks" с перечнем битых секторов, а выполняется совсем другая операция.
Может подскажете что теперь делать в этом случае? Т. е. например у меня флэшка битая и файловая система там не ext, и в наличии только консоль.
Так сложились звезды, что стал зависать у меня домашний сервачок. Да зависать намертво. Ну я его ресет, да ресет.. Вариантов то больше нет. Но после очередного ресета он перестал появляться в сети. Подключив монитор, я узрел его жалостливые крики о том что не откуда грузиться и мне бы хорошо INSERT SYSTEM DISK AND PRESS ENTER. Времени разбираться не было, поэтому я наскоро собрал замену, а вот руки посмотреть тот хард дошли только сейчас:
Как же быть, что же делать?!
На самом деле тот факт, что на диске присутствуют слайсы и партиции уже обнадеживает. Для самоуспокоения можно посмотреть мнение fdisk и bsdlabel:
Для начала надо сделать рабочую и резервную копии раздела.
Попутно проверим, остались ли на партиции данные об ФС и подготовим рабочий образ для дальнейших операций.
123456789_123456789_123456789_123456789-123456789-12465789-123456789-123456789-
Как видно, партиция не убита, на ней действительно есть UFS2 (aka FFS), но она
почему то не хочет монтироваться.
Если же у вас ситуация более запущена, возможно придется выковыривать останки
ФС с диска, в чем поможет sysutils/scan_ffs.
Одна из вероятных причин(с которой столкнулся я) - повреждение суперблока
(160-го блока для UFS2). для таких случаем предусмотрены резервные копии
суперблока, расположение которых выводится при создании файловой системы и
должно быть записано в надежном месте. Если вы не знаете что такое суперблок
и как устроена файловая система, то эту информацию стоит найти в Сети и
ознакомиться с ней
Если же у вас такой информации нет - посыпьте голову пеплом и воспользуйтесь newfs(8)
Какмы видим, партиция разделена на 4 "группы цилиндров" в каждой из которых
есть копия суперблока.
Пробуем проверить диск, принудительно используя альтернативный суперблок
Ура! =) Починили!
Теперь у нас в наличии корректный ОБРАЗ файловой системы - /usr/ad1s1a.img
при необходимости производим аналогичные действия с другими партициями, очень подозрительно проверяем диск на наличие ошибок. При необходимости заменяем диск и разбиваем его так, чтобы каждая новая партиция смогла вместить в себя содержимое старой партиции, после чего переносим содержимое старых партиций на новый диск через tar, pax или dump/restore, кому как больше нравится.
размещено: 2011-09-14,
последнее обновление: 2012-04-12,
автор: FreeBSP
А у Васи-то никогда в никуда не улатала какаянить табличка на сервере, или файл - раз он так смело советует не читая статьи.
Гость, 2013-04-28 в 23:22:27
У тебя видимо всё слетело,причём вместе с головой раз такой бред постоянно строчишь.
Vasya, 2014-03-15 в 5:12:23
Alex Keda, ты конченный ЕБЛАН. 1111111111111
ivaniy, 2014-09-10 в 4:28:26
У меня все было похоже, но после fsck много каталогов поудаляло и файлы перенесло в лост+фаунд. А именно весь bin, etc. Поскольку ето был сервер со своими настройками и перекомпилированым ядром, а времени небыло все наново делать, то тогда использовал md для оригинального образа mdconfig -a -t vnode -f /usr/ad1s1a.img.orig , и примаунтил его таким образом: mount -t ufs -o ro,noexec /dev/md0 /mnt/[i]
После етого мне удалось восстановить систему в исходное состояние
Алексей, 2015-01-16 в 23:21:42
Раздел на gmirror вылетел в аналогичную ситуацию после gpart resize и перезагрузки. Оба диска в зеркале оказались живы и здоровы, проблема в логической части.
Решилось так:
dd в файл, затем монтирование файла через md0
newfs на "поврежденном" разделе, его монтирование и копирование файлов со смонтированного файла.
В причинах нарушения зеркала разбираться не стал, наверное resize порушил какую-то логику
Alex, 2016-06-16 в 11:57:57
Нормально, но порой теряется часть логики принятия решения.
Например в команде fsck_ffs -b 262336 /dev/md0
не плохо было-бы разъяснить почему используется блок 262336, а не скажем 524512 или 786688 (или они равнозначны?)
Этот информационный блок появился по той простой причине, что многие считают нормальным, брать чужую информацию не уведомляя автора (что не так страшно), и не оставляя линк на оригинал и автора — что более существенно. Я не против распространения информации — только за. Только условие простое — извольте подписывать автора, и оставлять линк на оригинальную страницу в виде прямой, активной, нескриптовой, незакрытой от индексирования, и не запрещенной для следования роботов ссылки.
Если соизволите поставить автора в известность — то вообще почёт вам и уважение.
Проверка примонтированных файловых систем
Раньше я говорил что нельзя. Но если другого выхода нет, то можно, правда не рекомендуется. Для этого нужно сначала перемонтировать файловую систему в режим только для чтения. Например:
sudo mount -o remount,ro /dev/sdb1
А теперь проверка файловой системы fsck в принудительном режиме:
sudo fsck -fy /dev/sdb1
Просмотр информации
Если вы не хотите ничего исправлять, а только посмотреть информацию, используйте опцию -n:
sudo fsck -n /dev/sdb1
Проверка дисков fsck
Рано или поздно это случается, а именно крах системы или раздела, невозможность проверить файловую систему и т.д. Поэтому системный администратор должен знать что делать в таких ситуациях, так сказать знать как «Отче наш».
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. Ниже приведены их дефолтные значения:
Я рекомендую прописать в /etc/rc.conf только такое:
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 работает и в ручном режиме.
Восстановление поврежденного суперблока
Обычно эта команда справляется со всеми повреждениями на ура. Но если вы сделали что-то серьезное и повредили суперблок, то тут fsck может не помочь. Суперблок - это начало файловой системы. Без него ничего работать не будет.
Но не спешите прощаться с вашими данными, все еще можно восстановить. С помощью такой команды смотрим куда были записаны резервные суперблоки:
sudo mkfs -t ext4 -n /dev/sda1
На самом деле эта команда создает новую файловую систему. Вместо ext4 подставьте ту файловую систему, в которую был отформатирован раздел, размер блока тоже должен совпадать иначе ничего не сработает. С опцией -n никаких изменений на диск не вноситься, а только выводится информация, в том числе о суперблоках.
Теперь у нас есть шесть резервных адресов суперблоков и мы можем попытаться восстановить файловую систему с помощью каждого из них, например:
sudo fsck -b 98304 /dev/sda1
После этого, скорее всего, вам удастся восстановить вашу файловую систему. Но рассмотрим еще пару примеров.
Основы работы с fsck
В этой статье мы рассмотрим ручную работу с fsck. Возможно, вам понадобиться LiveCD носитель, чтобы запустить из него утилиту, если корневой раздел поврежден. Если же нет, то система сможет загрузиться в режим восстановления и вы будете использовать утилиту оттуда. Также вы можете запустить fsck в уже загруженной системе. Только для работы нужны права суперпользователя, поэтому выполняйте ее через sudo.
А теперь давайте рассмотрим сам синтаксис утилиты:
$ fsck [опции] [опции_файловой_системы] [раздел_диска]
Основные опции указывают способ поведения утилиты, оболочки fsck. Раздел диска - это файл устройства раздела в каталоге /dev, например, /dev/sda1 или /dev/sda2. Опции файловой системы специфичны для каждой отдельной утилиты проверки.
А теперь давайте рассмотрим самые полезные опции fsck:
- -l - не выполнять другой экземпляр fsck для этого жесткого диска, пока текущий не завершит работу. Для SSD параметр игнорируется;
- -t - задать типы файловых систем, которые нужно проверить. Необязательно указывать устройство, можно проверить несколько разделов одной командой, просто указав нужный тип файловой системы. Это может быть сама файловая система, например, ext4 или ее опции в формате opts=ro. Утилита просматривает все файловые системы, подключенные в fstab. Если задать еще и раздел то к нему будет применена проверка именно указанного типа, без автоопределения;
- -A - проверить все файловые системы из /etc/fstab. Вот тут применяются параметры проверки файловых систем, указанные в /etc/fstab, в том числе и приоритетность. В первую очередь проверяется корень. Обычно используется при старте системы;
- -C - показать прогресс проверки файловой системы;
- -M - не проверять, если файловая система смонтирована;
- -N - ничего не выполнять, показать, что проверка завершена успешно;
- -R - не проверять корневую файловую систему;
- -T - не показывать информацию об утилите;
- -V - максимально подробный вывод.
Это были глобальные опции утилиты. А теперь рассмотрим опции для работы с файловой системой, их меньше, но они будут более интересны:
Теперь мы все разобрали и вы готовы выполнять восстановление файловой системы linux. Перейдем к делу.
Ошибка Центра обновления 8007000E Windows 7 и Windows Server 2008R2
12 октября 2016 ВК Tw Fb
Ошибка 8007000E Центра обновления Windows (Windows Update), как ни странно, чаще всего встречается сразу же после чистой установки Windows 7 любой редакции . Не стоит паниковать: решение проблемы достаточно простое, достаточно иметь под рукой Интернет.
Ошибка при запуске приложения (0xc0000005). Для выхода из приложения нажмите кнопку «ОК»
В один прекрасный момент у одного из наших клиентов перестали запускаться все приложения (*.exe файлы). При чём связать появление данной проблемы с какими-то конкретными действиями так и не получилось. Выключали ПК – всё работало, включили .exe не запускаются. Решаем эту проблему!
Битые сектора
Или еще мы можем найти битые сектора и больше в них ничего не писать:
sudo fsck -c /dev/sda1
Проверка чистой файловой системы
Проверим файловую систему, даже если она чистая:
sudo fsck -fy /dev/sda1
Проверка диска на битые секторы Linux
Для поиска битых секторов можно использовать утилиту badblocks. Если вам надо проверить корневой или домашний раздел диска, то лучше загрузится в LiveCD, чтобы файловая система не была смонтирована. Все остальные разделы можно сканировать в вашей установленной системе. Вам может понадобиться посмотреть какие разделы есть на диске. Для этого можно воспользоваться командой fdisk:
sudo fdisk -l /dev/sda1
Или если вы предпочитаете использовать графический интерфейс, это можно сделать с помощью утилиты Gparted. Просто выберите нужный диск в выпадающем списке:
В этом примере я хочу проверить раздел /dev/sda2 с файловой системой XFS. Как я уже говорил, для этого используется команда badblocks. Синтаксис у неё довольно простой:
$ sudo badblocks опции /dev/имя_раздела_диска
Давайте рассмотрим опции программы, которые вам могут понадобится:
- -e - позволяет указать количество битых блоков, после достижения которого дальше продолжать тест не надо;
- -f - по умолчанию утилита пропускает тест с помощью чтения/записи если файловая система смонтирована чтобы её не повредить, эта опция позволяет всё таки выполнять эти тесты даже для смонтированных систем;
- -i - позволяет передать список ранее найденных битых секторов, чтобы не проверять их снова;
- -n - использовать безопасный тест чтения и записи, во время этого теста данные не стираются;
- -o - записать обнаруженные битые блоки в указанный файл;
- -p - количество проверок, по умолчанию только одна;
- -s - показывать прогресс сканирования раздела;
- -v - максимально подробный режим;
- -w - позволяет выполнить тест с помощью записи, на каждый блок записывается определённая последовательность байт, что стирает данные, которые хранились там раньше.
Таким образом, для обычной проверки используйте такую команду:
sudo badblocks -v /dev/sda2 -o ~/bad_sectors.txt
Это безопасно и её можно выполнять на файловой системе с данными, она ничего не повредит. В принципе, её даже можно выполнять на смонтированной файловой системе, хотя этого делать не рекомендуется. Если файловая система размонтирована, можно выполнить тест с записью с помощью опции -n:
sudo badblocks -vn /dev/sda2 -o ~/bad_sectors.txt
После завершения проверки, если были обнаружены битые блоки, надо сообщить о них файловой системе, чтобы она не пыталась писать туда данные. Для этого используйте утилиту fsck и опцию -l:
fsck -l ~/bad_sectors.txt /dev/sda1
Если на разделе используется файловая система семейства Ext, например Ext4, то для поиска битых блоков и автоматической регистрации их в файловой системе можно использовать команду e2fsck. Например:
sudo e2fsck -cfpv /dev/sda1
Параметр -с позволяет искать битые блоки и добавлять их в список, -f - проверяет файловую систему, -p - восстанавливает повреждённые данные, а -v выводит всё максимально подробно.
NTLDR is missing. BOOTMGR is missing
База знаний “Try 2 Fix”
Все материалы свободны
к распространению с обязательным
указанием источника
Рано или поздно это случается, а именно крах системы или раздела, невозможность проверить файловую систему и т.д. Поэтому системный администратор должен знать что делать в таких ситуациях, так сказать знать как «Отче наш».
1) fsck при загрузке ОС
Когда случается сбой питания в работу вступает fsck: file system consistency check and interactive repair или если на русском, то «проверка целосности файловой системы и интерактивное восстановление». По умолчанию проверка дисков отключена. Что бы её включить при загрузке системы, добавим такую строчку
в файл /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:
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 работает и в ручном режиме.
Остались вопросы?
Лоджик Флоу
Аутсорсинг / Системное администрирование / Техническая поддержка / Сопровождение 1С:Предприятие
Что-то пошло не так? Специалисты нашей компании помогут Вам разобраться с возникшими проблемами! Обращайтесь! →
Также Ваши вопросы Вы можете задать в нашей группе ВК или на нашем YouTube канале!
Эти статьи будут Вам интересны
Как восстановить файловую систему в fsck
Допустим, вы уже загрузились в LiveCD систему или режим восстановления. Ну, одним словом, готовы к восстановлению ext4 или любой другой поврежденной ФС. Утилита уже установлена по умолчанию во всех дистрибутивах, так что устанавливать ничего не нужно.
Восстановление файловой системы
Если ваша файловая система находится на разделе с адресом /dev/sda1 выполните:
sudo fsck -y /dev/sda1
Опцию y указывать необязательно, но если этого не сделать утилита просто завалит вас вопросами, на которые нужно отвечать да.
Немного теории
Как вы знаете файловая система содержит всю информацию обо всех хранимых на компьютере файлах. Это сами данные файлов и метаданные, которые управляют расположением и атрибутами файлов в файловой системе. Как я уже говорил, данные не сразу записываются на жесткий диск, а некоторое время находятся в оперативной памяти и при неожиданном выключении, за определенного стечения обстоятельств файловая система может быть повреждена.
Современные файловые системы делятся на два типа - журналируемые и нежурналируемые. Журналиуемые файловые системы записывают в лог все действия, которые собираются выполнить, а после выполнения стирают эти записи. Это позволяет очень быстро понять была ли файловая система повреждена. Но не сильно помогает при восстановлении. Чтобы восстановить файловую систему linux необходимо проверить каждый блок файловой системы и найти поврежденные сектора.
Для этих целей используется утилита fsck. По сути, это оболочка для других утилит, ориентированных на работу только с той или иной файловой системой, например, для fat одна утилита, а для ext4 совсем другая.
В большинстве систем для корневого раздела проверка fsck запускается автоматически, но это не касается других разделов, а также не сработает если вы отключили проверку.
Выводы
В этой статье мы рассмотрели как выполняется проверка диска на битые секторы Linux, чтобы вовремя предусмотреть возможные сбои и не потерять данные. Но на битых секторах проблемы с диском не заканчиваются. Там есть множество параметров стабильности работы, которые можно отслеживать с помощью таблицы SMART. Читайте об этом в статье Проверка диска в Linux.
Проверка всех файловых систем
С помощью флага -A вы можете проверить все файловые системы, подключенные к компьютеру:
Но такая команда сработает только в режиме восстановления, если корневой раздел и другие разделы уже примонтированы она выдаст ошибку. Но вы можете исключить корневой раздел из проверки добавив R:
Или исключить все примонтированные файловые системы:
Также вы можете проверить не все файловые системы, а только ext4, для этого используйте такую комбинацию опций:
sudo fsck -A -t ext4 -y
Или можно также фильтровать по опциям монтирования в /etc/fstab, например, проверим файловые системы, которые монтируются только для чтения:
sudo fsck -A -t opts=ro
Познаём fsck: краткий обзор возможностей : 2 комментария
fsck_y_enable=»YES» имеет несколько другое значение. А именно отвечать автоматом положительно на любой запрос fsck (согласно /etc/defaults/rc.conf). Что делать крайне нерекомендуется.
Из-за различных неполадок или неожиданного отключения компьютера файловая система может быть повреждена. При обычном выключении все файловые системы монтируются только для чтения, а все не сохраненные данные записываются на диск.
Но если питание выключается неожиданно, часть данных теряется, и могут быть потерянны важные данные, что приведет к повреждению самой файловой системы. В этой статье мы рассмотрим как восстановить файловую систему fsck, для нескольких популярных файловых систем, а также поговорим о том, как происходит восстановление ext4.
Читайте также: