Ext4 проверка и исправление ошибок

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

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

Немного теории

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

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

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

В большинстве систем для корневого раздела проверка 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 — максимально подробный вывод.

Это были глобальные опции утилиты. А теперь рассмотрим опции для работы с файловой системой, их меньше, но они будут более интересны:

• -a — во время проверки исправить все обнаруженные ошибки, без каких-либо вопросов. Опция устаревшая и ее использовать не рекомендуется;
• -n — выполнить только проверку файловой системы, ничего не исправлять;
• -r — спрашивать перед исправлением каждой ошибки, используется по умолчанию для файловых систем ext;
• -y — отвечает на все вопросы об исправлении ошибок утвердительно, можно сказать, что это эквивалент a.
• -c — найти и занести в черный список все битые блоки на жестком диске. Доступно только для ext3 и ext4;
• -f — принудительная проверка файловой системы, даже если по журналу она чистая;
• -b — задать адрес суперблока, если основной был поврежден;
• -p — еще один современный аналог опции -a, выполняет проверку и исправление автоматически. По сути, для этой цели можно использовать одну из трех опций: p, a, y.

Теперь мы все разобрали и вы готовы выполнять восстановление файловой системы linux. Перейдем к делу.

Как восстановить файловую систему в fsck

Допустим, вы уже загрузились в LiveCD систему или режим восстановления. Ну, одним словом, готовы к восстановлению ext4 или любой другой поврежденной ФС. Утилита уже установлена по умолчанию во всех дистрибутивах, так что устанавливать ничего не нужно.

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

Если ваша файловая система находится на разделе с адресом /dev/sda1 выполните:

sudo fsck -y /dev/sda1

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

Восстановление поврежденного суперблока

Обычно эта команда справляется со всеми повреждениями на ура. Но если вы сделали что-то серьезное и повредили суперблок, то тут fsck может не помочь. Суперблок — это начало файловой системы. Без него ничего работать не будет.

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

sudo mkfs -t ext4 -n /dev/sda1

На самом деле эта команда создает новую файловую систему. Вместо ext4 подставьте ту файловую систему, в которую был отформатирован раздел, размер блока тоже должен совпадать иначе ничего не сработает. С опцией -n никаких изменений на диск не вноситься, а только выводится информация, в том числе о суперблоках.

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

sudo fsck -b 98304 /dev/sda1

После этого, скорее всего, вам удастся восстановить вашу файловую систему. Но рассмотрим еще пару примеров.

Проверка чистой файловой системы

Проверим файловую систему, даже если она чистая:

sudo fsck -fy /dev/sda1

Битые сектора

Или еще мы можем найти битые сектора и больше в них ничего не писать:

sudo fsck -c /dev/sda1

Установка файловой системы

Вы можете указать какую файловую систему нужно проверять на разделе, например:

sudo fsck -t ext4 /dev/sdb1

Проверка всех файловых систем

С помощью флага -A вы можете проверить все файловые системы, подключенные к компьютеру:

sudo fsck -A -y

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

sudo fsck -AR -y

Или исключить все примонтированные файловые системы:

sudo fsck -M -y

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

sudo fsck -A -t ext4 -y

Или можно также фильтровать по опциям монтирования в /etc/fstab, например, проверим файловые системы, которые монтируются только для чтения:

sudo fsck -A -t opts=ro

Проверка примонтированных файловых систем

Раньше я говорил что нельзя. Но если другого выхода нет, то можно, правда не рекомендуется. Для этого нужно сначала перемонтировать файловую систему в режим только для чтения. Например:

sudo mount -o remount,ro /dev/sdb1

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

sudo fsck -fy /dev/sdb1

Просмотр информации

Если вы не хотите ничего исправлять, а только посмотреть информацию, используйте опцию -n:

sudo fsck -n /dev/sdb1

Выводы

Вот и все, теперь вы знаете как выполняется восстановление файловой системы ext4 или любой другой, поддерживаемой в linux fsck. Если у вас остались вопросы, спрашивайте в комментариях!

На десерт сегодня видео на английском про различия файловых систем ext4 и xfs, как обычно, есть титры:

https://www.youtube.com/watch?v=pECp066gGcY

Обнаружили ошибку в тексте? Сообщите мне об этом. Выделите текст с ошибкой и нажмите Ctrl+Enter.

Оригинал: 4 Tools to Manage EXT2, EXT3 and EXT4 Health in Linux

Автор: Aaron Kili

Дата публикации: 6 ноября 2017 года

Перевод: А. Кривошей

Дата перевода: январь 2018 г.

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

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

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

В этой статье мы рассмотрим инструменты для мониторинга и поддержания работоспособности файловых систем ext2, ext3 и ext4. Все описанные здесь утилиты требуют привилегий пользователя root, поэтому для их запуска используйте команду sudo.

Как просмотреть информацию о файловой системе EXT2/EXT3/EXT4

dumpe2fs — утилита командной строки, используемая для вывода данных о файловой системе ext2/ext3/ ext4, она отображает информацию о суперблоке и блоках для файловой системы на устройстве.

Перед запуском dumpe2fs обязательно запустите команду df -hT, чтобы узнать имена устройств файловой системы.

$ sudo dumpe2fs /dev/sda10

Пример вывода

Для просмотра блоков, помеченных в файловой системе как плохие, используйте флаг -b:

$ dumpe2fs -b

Проверка файловых систем EXT2/EXT3/EXT4 на наличие ошибок

e2fsck используется для проверки файловых систем ext2/ext3/ext4 на наличие ошибок, а fsck проверяет и может при необходимости исправлять ошибки файловой системы Linux. Она, в основном, представляет собой интерфейс для утилит, проверяющих различные файловой системы, используемые в Linux (fsck.fstype, например fsck.ext3, fsck.sfx и т. д.).

Помните, что при загрузке системы Linux автоматически запускает e2fack/fsck на разделах, помеченных для проверки в конфигурационном файле /etc/fstab. Обычно это делается после того, как файловая система не была правильно отмонтирована.

Внимание: не запускайте e2fsck или fsck на смонтированных файловых системах, сначала отмонтируйте раздел, как показано ниже.

$ sudo unmount /dev/sda10
$ sudo fsck /dev/sda10

В качестве альтернативы вы можете включить подробный вывод с помощью ключа -V и указать тип файловой системы с помощью ключа -t:

$ sudo fsck -Vt ext4 /dev/sda10

Настройка файловых систем EXT2/EXT3/EXT4

В начале мы упоминали, что одной из причин повреждения файловой системы является ее неправильная настройка. Для изменения настраиваемых параметров файловых систем ext2/ext3 /ext4 вы можете использовать утилиту tune2fs , как описано ниже.

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

$ sudo tune2fs -l /dev/sda10

Пример вывода:

Далее, с помощью флага -c, вы можете установить количество монтирований, после которого файловая система будет проверена утилитой e2fsck. Приведенная ниже команда указывает системе запустить e2fsck на /dev/sda10 после каждых 4 монтирований.

$ sudo tune2fs -c 4 /dev/sda10
tune2fs 1.42.13 (17-May-2015)
Setting maximal mount count to 4

Вы также можете задать время между двумя проверками файловой системы с помощью опции -i. Приведенная ниже команда устанавливает интервал между проверками файловой системы 2 дня.

$ sudo tune2fs  -i  2d  /dev/sda10
tune2fs 1.42.13 (17-May-2015)
Setting interval between checks to 172800 seconds

Теперь, если вы запустите приведенную ниже команду, будет установлен интервал проверки файловой системы для /dev /sda10.

$ sudo tune2fs -l /dev/sda10

Пример вывода:

Для изменения параметров ведения журнала по умолчанию используется параметр -J. Этот параметр также имеет подпараметры: size = journal-size (устанавливает размер журнала), device = external-journal (указывает устройство, на котором он хранится) и location = journal-location (определяет местоположение журнала).

Обратите внимание, что для файловой системы можно задать только один из параметров: размер или устройство:

$ sudo tune2fs -J size=4MB /dev/sda10

И последнее, но не менее важное: метку тома файловой системы можно задать с помощью опции -L, как показано ниже.

$ sudo tune2fs -L "ROOT" /dev/sda10

Отладка файловых систем EXT2/EXT3/EXT4

debugfs — простой, интерактивный консольный отладчик файловой системы ext2/ext3/ext4. Он позволяет изменять параметры файловой системы в интерактивном режиме. Чтобы просмотреть его команды или запросы, введите «?».

$ sudo debugfs /dev/sda10

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

Пример вывода:

debugfs 1.42.13 (17-May-2015)
debugfs:  ?
Available debugfs requests:
show_debugfs_params, params
Show debugfs parameters
open_filesys, open       Open a filesystem
close_filesys, close     Close the filesystem
freefrag, e2freefrag     Report free space fragmentation
feature, features        Set/print superblock features
dirty_filesys, dirty     Mark the filesystem as dirty
init_filesys             Initialize a filesystem (DESTROYS DATA)
show_super_stats, stats  Show superblock statistics
ncheck                   Do inode->name translation
icheck                   Do block->inode translation
change_root_directory, chroot
....

Для определения фрагментации свободного пространства используется запрос freefrag:

debugfs: freefrag

Пример вывода:

Device: /dev/sda10
Blocksize: 4096 bytes
Total blocks: 86154752
Free blocks: 22387732 (26.0%)
Min. free extent: 4 KB 
Max. free extent: 2064256 KB
Avg. free extent: 2664 KB
Num. free extent: 33625
HISTOGRAM OF FREE EXTENT SIZES:
Extent Size Range :  Free extents   Free Blocks  Percent
4K...    8K-  :          4883          4883    0.02%
8K...   16K-  :          4029          9357    0.04%
16K...   32K-  :          3172         15824    0.07%
32K...   64K-  :          2523         27916    0.12%
64K...  128K-  :          2041         45142    0.20%
128K...  256K-  :          2088         95442    0.43%
256K...  512K-  :          2462        218526    0.98%
512K... 1024K-  :          3175        571055    2.55%
1M...    2M-  :          4551       1609188    7.19%
2M...    4M-  :          2870       1942177    8.68%
4M...    8M-  :          1065       1448374    6.47%
8M...   16M-  :           364        891633    3.98%
16M...   32M-  :           194        984448    4.40%
32M...   64M-  :            86        873181    3.90%
64M...  128M-  :            77       1733629    7.74%
128M...  256M-  :            11        490445    2.19%
256M...  512M-  :            10        889448    3.97%
512M... 1024M-  :             2        343904    1.54%
1G...    2G-  :            22      10217801   45.64%
debugfs:  

Вы можете использовать также множество других запросов, таких как создание или удаление файлов или каталогов, изменение текущего рабочего каталога и многое другое, просто почитайте краткое описание запросов. Для закрытия debugfs введите запрос q.

Другие статьи о мониторинге и обслуживании файловых систем в Linux:

• Pyinotify – мониторинг изменений файловой системы Linux в режиме реального времени
• Inotify-tools: осуществляем мониторинг изменении файловой системы в Linux
• Мониторинг файловых операций с помощью демона auditd
• Повреждение файловой системы после отключения питания или система рухнула

---

Состояние перевода: На этой странице представлен перевод статьи fsck. Дата последней синхронизации: 10 июля 2021. Вы можете помочь синхронизировать перевод, если в английской версии произошли изменения.

fsck (file system check) — утилита для проверки и восстановления файловых систем Linux. Проверка файловых систем разных физических дисков выполняется параллельно, что позволяет значительно её ускорить (см. fsck(8)).

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

Проверка при загрузке

Механизм

Существует два возможных варианта:

1. mkinitcpio предоставляет хук fsck для проверки корневой файловой системы перед монтированием. Корневой раздел должен быть смонтирован на запись и чтение (параметр ядра rw) [1].
2. systemd проверяет все файловые системы, которым задано значение fsck больше 0 (либо параметром fstab, либо в пользовательском файле юнита). Корневая файловая система изначально должна быть смонтирована только на чтение (параметр ядра ro), и лишь позже перемонтирована на чтение-запись в fstab. Имейте в виду, что опция монтирования defaults подразумевает rw.

Рекомендуется по умолчанию использовать первый вариант. Если вы устанавливали систему в соответствии с руководством, то использоваться будет именно он. Если вы хотите вместо этого использовать вариант 2, то удалите хук fsck из mkinitcpio.conf и задайте параметр ядра ro. Кроме того, параметром ядра fsck.mode=skip можно полностью отключить fsck для обоих вариантов.

Принудительная проверка

Если вы используете base-хук mkinitcpio, то можно принудительно выполнять fsck во время загрузки, задав параметр ядра fsck.mode=force. Проверена будет каждая файловая система на машине.

В качестве альтернативы можно воспользоваться службой systemd systemd-fsck@.service(8), которая проверит все настроенные файловые системы, которые не были проверены в initramfs. Тем не менее, проверка корневой файловой системы этим способом может стать причиной задержки в время загрузки, поскольку файловая система будет перемонтироваться.

Примечание: Если вы используете другие дистрибутивы GNU/Linux, то учтите, что старые методы проверки вроде файлов forcefsck для каждой файловой системы или команды shutdown с флагом -F будут работать только с SysVinit и ранними версиями Upstart; работать с systemd они не будут. Решение, предложенное выше, является единственным рабочим для Arch Linux.

Советы и рекомандации

Восстановление повреждённых блоков

Следующая команда позволяет восстановить повреждённые участки файловых систем ext2/ext3/ext4 и FAT:

Важно: Разрешение на восстановление запрошено не будет. Подразумевается, что вы уже ответили «Да», запустив команду на выполнение.

# fsck -a

Интерактивное восстановление повреждённых блоков

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

# fsck -r диск

Изменение частоты проверки

Примечание: Команды tune2fs и dumpe2fs работают только с файловыми системами ext2/ext3/ext4.

По умолчанию fsck проверяет файловую систему каждые 30 загрузок (вычисляется отдельно для каждого раздела). Чтобы изменить частотку проверок, выполните:

# tune2fs -c 20 /dev/sda1

Здесь 20 — число загрузок между проверками. Если задать значение 1, то проверка будет выполняться при каждой загрузке, а значение 0 отключит сканирование.

Текущую частоту проверок и опции монтирования конкретного раздела можно узнать командой:

# dumpe2fs -h /dev/sda1 | grep -i 'mount count'

Параметры fstab

fstab — файл системных настроек, который используется для передачи ядру Linux информации о том, какие разделы (файловые системы) монтировать и в какие точки дерева файловой системы.

Записи в /etc/fstab выглядят примерно следующим образом.

/dev/sda1   /         ext4      defaults       0  1
/dev/sda2   /other    ext4      defaults       0  2
/dev/sda3   /win      ntfs-3g   defaults       0  0

Шестое поле каждой строки (выделено) — опция fsck:

• 0 — не проверять.
• 1 — файловая система (раздел), которая должна быть проверена первой; для корневого раздела (/) должно использоваться именно это значение.
• 2 — прочие файловые системы, которые должны быть проверены.

Решение проблем

Не запускается fsck для отдельного раздела /usr

1. Убедитесь, что используются соответствующие хуки в /etc/mkinitcpio.conf, а также что вы не забыли пересоздать initramfs после последнего редактирования этого файла.
2. Проверьте fstab! Только корневому разделу должен быть задан параметр 1 в последнем поле, все остальные разделы должны иметь либо 2, либо 0. Также проверьте файл на наличие иных опечаток.

ext2fs: no external journal

Иногда (например, из-за внезапного отключения питания) файловые системы ext(3/4) могут повредиться так сильно, что восстановить их обычным способом не удастся. Как правило, при этом fsck выводит сообщение о том, что не удалось найти журнал (no external journal). В этом случае выполните команды ниже.

Отмонтируйте раздел от соответствующего каталога:

# umount каталог

Запишите на раздел новый журнал:

# tune2fs -j /dev/раздел

Запустите fsck, чтобы восстановить раздел:

# fsck -p /dev/раздел