Freebsd fsck проверка диска

Обновлено: 06.07.2024


Так сложились звезды, что стал зависать у меня домашний сервачок. Да зависать намертво. Ну я его ресет, да ресет.. Вариантов то больше нет. Но после очередного ресета он перестал появляться в сети. Подключив монитор, я узрел его жалостливые крики о том что не откуда грузиться и мне бы хорошо 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 (или они равнозначны?)

Этот информационный блок появился по той простой причине, что многие считают нормальным, брать чужую информацию не уведомляя автора (что не так страшно), и не оставляя линк на оригинал и автора — что более существенно. Я не против распространения информации — только за. Только условие простое — извольте подписывать автора, и оставлять линк на оригинальную страницу в виде прямой, активной, нескриптовой, незакрытой от индексирования, и не запрещенной для следования роботов ссылки.
Если соизволите поставить автора в известность — то вообще почёт вам и уважение.

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

в файл /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. Это можно заметить только тогда, когда случился серъёзный крах.

Есть несколько параметров, которые прописываются в /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. Загружаемся в Single User Mode(Одно пользовательский режим) или используем Rescue-CD диск.

2. Отмонтируем файловую систему.

y — отвечать yes на все вопросы (альтернатива: ключ p — запускает проверку в полностью автоматическом режиме);
f — принудительная проверка (проводится даже если файловая система помечена как работоспособная);
c — искать битые блоки (bad blocks) и помечать их соответствующим образом;
/dev/sda1 — устройство и раздел, которые следует проверять (в данном случае, указан первый раздел первого диска).
v – verbose, будет выводить детальную информацию на терминал

Если есть вопросы, то просим Вас посетить наш форум, на котором Вы сможете попросить бесплатно описание.

Проверка дисков fsck

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

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

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

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

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

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

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

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

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

Я рекомендую прописать в /etc/rc.conf только такое:

И так, вот примеры работы 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

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

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

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

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

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

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

FreeBSD 11: Проверка состояния SMART жёстких дисков

fsck проверка диска freebsd

Проверка SMART жёсткого диска — важная операция, которую надо проводить время от времени. Если в Windows это можно просто сделать с помощью россыпи программ с графическим интерфейсом, то во FreeBSD (если нет GUI) сделать это немного сложнее. Но мы справимся!

  1. Для начала установим всё необходимое из портов. Переходим в
  2. Устанавливаем
  3. Получаем список дисков и разделов

На выходе получим что-то такое

Первая строка — это сам HDD, остальные это разделы на нём. В данном случае у нас один SATA HDD с тремя разделами на нём.
А дальше подставляем название HDD в команду, которой мы можем воспользоваться благодаря установленному порту

Появляется довольно обширная информация по состоянию выбранного HDD. В этом конкретном случаем HDD больше не пригоден для использования, так как у атрибута Reallocated_Sector статус FAILING_NOW. Беда!

Остались вопросы?

Лоджик Флоу

Аутсорсинг / Системное администрирование / Техническая поддержка / Сопровождение 1С:Предприятие

Что-то пошло не так? Специалисты нашей компании помогут Вам разобраться с возникшими проблемами! Обращайтесь! →

Также Ваши вопросы Вы можете задать в нашей группе ВК или на нашем YouTube канале!

Эти статьи будут Вам интересны

Ошибка при запуске приложения (0xc0000005). Для выхода из приложения нажмите кнопку «ОК»

Ошибка Центра обновления 8007000E Windows 7 и Windows Server 2008R2

12 октября 2016 ВК Tw Fb

Ошибка 8007000E Центра обновления Windows (Windows Update), как ни странно, чаще всего встречается сразу же после чистой установки Windows 7 любой редакции . Не стоит паниковать: решение проблемы достаточно простое, достаточно иметь под рукой Интернет.

NTLDR is missing. BOOTMGR is missing

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

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

Это можно сделать с помощью системной утилиты fsck (проверка целостности файловой системы). Эта проверка может выполняться автоматически во время загрузки или запускаться вручную.

Когда использовать fsck в Linux

Есть разные сценарии, когда вы захотите запустить fsck. Вот несколько примеров:

  • Система не загружается.
  • Файлы в системе повреждаются (часто вы можете увидеть ошибку ввода/вывода).
  • Подключенный диск (включая флешки/SD-карты) не работает должным образом.

Опции программы fsck

Команду fsck необходимо запускать с привилегиями суперпользователя или root. Вы можете использовать её с разными аргументами. Их использование зависит от вашего конкретного случая. Ниже вы увидите некоторые из наиболее важных опций:

Как запустить fsck для исправления ошибок файловой системы Linux

Чтобы запустить fsck, вам нужно убедиться, что раздел, который вы собираетесь проверить, не смонтирован. Для целей этой статьи я буду использовать свой второй диск /dev/sda, смонтированный в /mnt/disk_d.

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


Если диск не только смонтирован, но и используется (например, диск, смонтированный в корневую файловую систему), то ошибка будет «/dev/nvme0n1 is in use».

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

Тогда можно будет безопасно запускать fsck.


Понимание кодов выхода fsck

После запуска fsck он вернёт код выхода. Эти коды можно увидеть в руководстве по fsck, запустив:

Описание кодов выхода fsck:

Флаг -y означает автоматически отвечать «да» на любые запросы от fsck для исправления ошибки.

Точно так же вы можете запустить то же самое во всех файловых системах (с пропуском корневой файловой системы):

Как запустить fsck на корневом разделе Linux

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

  • Принудительно использовать fsck при загрузке системы
  • Запустите fsck в режиме восстановления

Мы рассмотрим обе ситуации.

Как принудительно проверить диск с помощью fsck при загрузке системы

Это относительно легко выполнить, единственное, что вам нужно сделать, это создать файл с именем forcefsck в корневом разделе вашей системы. Используйте следующую команду:

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

После загрузки системы проверьте, существует ли ещё файл:

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

Как запустить fsck в режиме восстановления

Для запуска fsck в режиме восстановления требуется ещё несколько шагов. Сначала подготовьте вашу систему к перезагрузке. Остановите все критически важные службы, такие как MySQL/MariaDB и т. д., а затем введите.

Во время загрузки удерживайте нажатой клавишу Shift, чтобы отобразилось меню grub. Выберите Advanced options («Дополнительные параметры»).


Затем выберите Recovery mode («Режим восстановления»).


В следующем меню выберите «fsck».


Вас спросят, хотите ли вы перемонтировать / файловую систему. Выберите Yes («да»).


Вы должны увидеть нечто подобное.


Затем вы можете вернуться к нормальной загрузке, выбрав Resume («Возобновить»).


Заключение

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

Читайте также: