Как проверить lvm на ошибки

Параметры fsck
Пример проверки диска на ошибки с помощью fsck
Запуск автоматической проверки и исправления найденных ошибок
Ручное добавление параметров в меню GRUB при загрузке ОС
Добавление параметров в меню GRUB с помощью утилиты grubby
Создание файла /forcefsck
Запуск проверки в ручном режиме
Использование загрузочного диска/flash для проверки файловой системы на ошибки
Проверка LVM-разделов с помощью утилиты fsck

В определенных случаях  (в результате сбоя или некорректного завершения работы)  на файловой системе могут накапливаться ошибки. В РЕД ОС для проверки файловой системы и исправления ошибок имеется утилита  fsck («file system consistency check»).

Инструмент fsck обладает следующим функционалом:

• проверка файловой системы при возникновении проблем (не загружается система/поврежденные файлы) или в качестве профилактического обслуживания;

• диагностика состояния внешних накопителей, таких как SD-карты или USB-накопители.

Базовый синтаксис соответствует следующему шаблону:

 fsck <опции> <файловая_система>

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

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

Параметры fsck

fsck –p – утилита автоматически исправит найденные ошибки.

Вывод аналогичен простой проверке.

fsck –с – проверка файловой системы на поврежденные сектора.

Для получения списка команд наберите fsck ––help или fsck –h.

Пример проверки диска на ошибки с помощью fsck

Запуск автоматической проверки и исправления найденных ошибок

Существует несколько способов запуска автоматической проверки на ошибки:

1. Ручное добавление параметров в меню GRUB при загрузке ОС.

2. Добавление параметров в меню GRUB с помощью утилиты grubby.

3. Создание файла /forcefsck.

1. Ручное добавление параметров в меню GRUB при загрузке ОС

Первый вариант проверки и  исправления ошибок на разделах жесткого диска.

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

fsck.mode=force fsck.repair=yes

в конец предпоследней строки.

Нажмите Ctrl+Х для запуска ОС с этими параметрами, во время запуска будет произведена проверка разделов диска, и при наличии ошибок произведено их исправление.

2. Добавление параметров в меню GRUB с помощью утилиты grubby

Существует еще один способ добавления параметров ядра для принудительной проверки файловой системы на ошибки и их исправления. Добавить параметры можно командой:

grubby --update-kernel /boot/vmlinuz-$(uname -r) --args="fsck.mode=force fsck.repair=yes"

Удалить установленные параметры можно следующей командой:

grubby --update-kernel /boot/vmlinuz-$(uname -r) --remove-args="fsck.mode=force fsck.repair=yes"

3. Создание файла /forcefsck

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

sudo touch /forcefsck

Команда sudo (после ввода пароля) предоставит права для создания с помощью touch пустого файла в корне диска /forcefsck, который послужит сигналом (флагом) для fsck, что нужно проверить диски. 

Останется только перезагрузить компьютер и fsck начнет проверять все жесткие диски, указанные в /etc/fstab.

Запуск проверки в ручном режиме

Следующий метод относится к проверке диска, когда операционная система загружена в режиме single mode.

1. Запустим ОС в single mode, для этого пропишите в меню загрузки grub параметр init=/bin/bash в конце строки, которая начинается на linux16, см. рисунок.

Также данная строка может начинаться с linuxefi, этот параметр характерен для систем с загрузкой в UEFI. Нажмите «ctrl+x» для запуска с этим параметром(init=/bin/bash).

2. Запустите проверку выполнив команду:

/usr/sbin/fsck -ACVfyv

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

Наглядное видео примера проверки диска на ошибки:

Использование загрузочного диска/flash для проверки файловой системы на ошибки.

Загрузившись в режим восстановления операционной системы РЕД ОС с помощью загрузочного диска или съемного накопителя с установленным образом операционной системы РЕД ОС. Выберите пункт: «Решение проблем» -> «Исправить установленную RED OS».

Система перезагрузится в режим восстановления. Введите «2» и нажмите 2 раза Enter. Так вы смонтируете операционную систему в режим «Только для чтения»

setfont cyr-sun16

Потом введите команду:

# сhroot /mnt/sysimage

После этого можете вводить fsck:

# fsck -ACVfyv

Если проверка завершится с такой ошибкой:

[путь_к_файловой_системе] is mounted

Введите:

umount [путь_к_файловой_системе]

И еще раз запустите утилиту fsck:

# fsck -ACVfyv
fsck from util-linux 2.30.2
…

Если система не выявит ошибок, то получится такой вывод:

[путь_к_файловой_системе] clean …

Чтобы выйти из режима восстановления, вы должны смонтировать все разделы, которые были отмонтированы командой umount, с помощью команды mount, нажать сочетание клавиш сtrl+d, а затем ввести команду reboot, которая перезапустит вашу операционную систему.

# reboot

По умолчанию, утилита fsck при проверке будет использовать разделы, указанные в /etc/fstab/, сформированные при установке операционной системы РЕД ОС.

Проверка LVM-разделов с помощью утилиты fsck

Перед проведением проверки необходимо найти устройство и размонтировать его.

Для просмотра всех подключенных устройств и проверки расположения диска выполните команду:

lsblk 

 NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
 sda 8:0 0 20G 0 disk 
 ├─sda1 8:1 0 1G 0 part /boot
 └─sda2 8:2 0 19G 0 part 
 ├─ro_redos-root 253:0 0 17G 0 lvm /
 └─ro_redos-swap 253:1 0 2G 0 lvm [SWAP]
 sr0 11:0 1 4,3G 0 rom /run/media/user/redos-MUROM-7.3.1 x86_64

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

fsck -nf /dev/ro_redos/root 

 fsck из util-linux 2.37.3
 e2fsck 1.44.6 (5-Mar-2019)
 Warning! /dev/mapper/ro_redos-root is mounted.

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

umount <файловая_система>

Однако попытка выполнить данную процедуру на работающей ОС ни к чему не приведет.

umount /dev/ro_redos/root 

 umount: /: target is busy.

Также проблемой при попытке проверить LVM-разделы может быть и то, что они являются не активными. Для проверки следует использовать команду:

lvscan 

 ACTIVE            '/dev/ro_redos/swap' [2,00 GiB] inherit
 ACTIVE            '/dev/ro_redos/root' [<17,00 GiB] inherit

Для активации раздела служит команда:

vgchange –ay <раздел>

Таким образом, можно сделать вывод, что проверка LVM-разделов через консоль с использованием утилиты fsck невозможна. Но это не значит, что LVM-разделы совсем не подлежат проверке. Существует как минимум два способа, позволяющие провести диагностику LVM-разделов. 

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

А вторым — запуск утилиты fsck в live-сессии системы.

Очевидным плюсом при проверке дисковых пространств, в том числе LVM-разделов, через live-сессию является то, что разделы там по умолчанию являются не смонтированными. Поэтому проверка LVM-раздела будет выполнена с первого раза.

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

Программа fsck (расшифровывается как File System Consistency Check) используется для проверки и восстановления одной или нескольких файловых систем Linux.

Эта проверка запускается автоматически во время загрузки при обнаружении несоответствий в файловой системе.

Также, при необходимости, она может быть запущена вручную.

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

В этой статье мы рассмотрим, как использовать команду ‘fsck’ или ‘e2fsck’ в Linux для восстановления поврежденной файловой системы.

🗂️ Что такое Ext2, Ext3 и Ext4 и как создавать и конвертировать файловые системы Linux

Примечание:

Выполняйте fsck на немонтированной файловой системе, чтобы избежать повреждения данных в ФС.

Для больших файловых систем выполнение fsck может занять много времени в зависимости от скорости системы и размера диска.

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

Общий синтаксис:

fsck [option] [device or partition or mount point]

Повреждение файловой системы EXT4

Мы намеренно повредим файловую систему EXT4, выполнив приведенную ниже команду.

Она удаляет случайно выбранные блоки метаданных файловой системы

Примечание: Пожалуйста, не тестируйте это на производственном сервере, так как это может сильно повредить ваши данные.

sudo umount /data

Повреждение файловой системы ext4.

sudo dd if=/dev/zero of=/dev/sdb1 bs=10000 skip=0 count=1

1+0 records in
1+0 records out
10000 bytes (10 kB, 9.8 KiB) copied, 0.00394663 s, 2.5 MB/s

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

sudo mount /data

mount: /data: wrong fs type, bad option, bad superblock on /dev/sdb1, missing codepage or helper program, or other error.

Восстановление поврежденной файловой системы EXT4 и EXT3

Вы можете восстановить поврежденную файловую систему ext3 или ext4 в работающей системе Linux. fsck работает как обертка для команд fsck.ext3 и fsck.ext4.

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

Шаг-1: Размонтируйте устройство, на котором вы хотите запустить fsck.

sudo umount /dev/sdb1

Шаг-2: Запустите fsck для восстановления файловой системы:

sudo fsck.ext4 -p /dev/sdb1

-p : Автоматически устранить все проблемы, которые могут быть безопасно устранены без вмешательства пользователя.

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

sudo fsck.ext4 -fvy /dev/sdb1

e2fsck 1.45.6 (20-Mar-2020)
ext2fs_open2: Bad magic number in super-block
fsck.ext4: Superblock invalid, trying backup blocks...
Resize inode not valid.  Recreate? yes

Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  -65536 -65538 -(65541--65542) -(65546--65547) -(65549--65550) -(65555--65557)
.
.
Fix? yes

Free inodes count wrong for group #0 (8181, counted=8165).
Fix? yes

Free inodes count wrong (327669, counted=327653).
Fix? yes

Padding at end of inode bitmap is not set. Fix? yes


/dev/sdb1: ***** FILE SYSTEM WAS MODIFIED *****

          27 inodes used (0.01%, out of 327680)
           0 non-contiguous files (0.0%)
           0 non-contiguous directories (0.0%)
             # of inodes with ind/dind/tind blocks: 0/0/0
             Extent depth histogram: 19
       43294 blocks used (3.30%, out of 1310464)
           0 bad blocks
           0 large files

          16 regular files
           2 directories
           0 character device files
           0 block device files
           0 fifos
           0 links
           0 symbolic links (0 fast symbolic links)
           0 sockets
------------
          18 files

Шаг-3: Как только файловая система будет восстановлена, смонтируйте раздел.

sudo mount /dev/sdb1

2) Восстановление тома LVM с помощью fsck

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

Для восстановления LVM-раздела следуйте приведенной ниже процедуре:

При необходимости вы также можете восстановить/восстановить том lvm вместо его ремонта.

Шаг-1: Убедитесь, что конкретный том LVM находится в активном состоянии для запуска fsck.

Чтобы проверить состояние LVM, выполните:

sudo lvscan

  inactive          '/dev/myvg/vol01' [1.00 GiB] inherit
  ACTIVE            '/dev/rhel/swap' [2.07 GiB] inherit
  ACTIVE            '/dev/rhel/root' [<26.93 GiB] inherit

Если он “inactive“, активируйте его, выполнив следующую команду.

sudo lvchange -ay /dev/myvg/vol01 -v

  Activating logical volume myvg/vol01.
  activation/volume_list configuration setting not defined: Checking only host tags for myvg/vol01.
  Creating myvg-vol01
  Loading table for myvg-vol01 (253:2).
  Resuming myvg-vol01 (253:2).

Шаг-2: Размонтируйте устройство или файловую систему, на которой вы хотите запустить fsck.

sudo umount /dev/myvg/vol01

Шаг-3: Запустите fsck для восстановления файловой системы.

Для запуска fsck необходимо ввести путь к LVM-тому, а не к реальному физическому разделу.

sudo fsck.ext4 -fvy /dev/myvg/vol01

e2fsck 1.45.6 (20-Mar-2020)
/dev/myvg/vol01: clean, 24/65536 files, 14094/262144 blocks

• -f : Принудительная проверка, даже если файловая система кажется чистой.
• -y : Предполагать ответ `yes’ на все вопросы; позволяет использовать e2fsck неинтерактивно.
• -v : Подробный режим

Шаг-4: Как только файловая система будет восстановлена, смонтируйте раздел.

sudo mount /apps

Заключение

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

Вы можете использовать ту же процедуру для EXT3 и других файловых систем.

Также мы показали, как запустить e2fsck на томах LVM.

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

см. также:

• 🐧 Как принудительно выполнить fsck при перезагрузке системы
• #️⃣ Как добавить зашифрованный жесткий диск на Linux
• 🛑 Команды Linux, которые вы никогда не должны запускать в своей системе
• 🐧 Советы по обеспечению безопасности сервера CentOS – часть 1
• 🐧 Проверка файловой системы Linux на наличие ошибок: команда FSCK с примерами
• 🐧 Как зашифровать каталоги с помощью eCryptfs на Linux

pvck can check LVM metadata, after that consistency is the job of the filesystem. LVM is only about volume management so it doesn’t need to care if the space constituting a particular extent is bad since higher level software catches those issues. LVM metadata only takes up the first (optionally also the last sector) of the physical volume anyways.

If just the first and last sectors of a reasonably large PV (such as you’d see in production) just happen to fail simultaneously, you basically have the sh*ttiest luck in the world since that’s so astronomically unlikely. Otherwise, if the admin knows multiple sectors of the drive have been failing, most people are alright with just filing such things as this under «hard drive failed permanently and needs to be replaced.»

If pvck returns an error, you can check to see if your LVM metadata is backed up in /etc/lvm somewhere. If it is you can do pvcreate specifying the backup copy to --restorefile

Syntax:

pvcreate --uuid "<UUID-of-target-PV>" --restorefile <Path-To-Metadata-Backup-File> <path-to-PV-block-device>

Example:

pvcreate --uuid "2VydVW-TNiN-fz9Y-ElRu-D6ie-tXLp-GrwvHz" --restorefile /etc/lvm/archive/vg_raid_00000-1085667159.vg /dev/sda2 

If the restore doesn’t work (for example, if the first sector is bad) you can re-do the above, but set --metadatacopies 2 (or you might just go straight to doing that) which will attempt to write the metadata to the first and last sectors on the PV. When pvscan does its thing on boot it will check both places and if it finds metadata it will verify them against a checksum. If the checksum fails on the first sector but succeeds on the last sector you’ll get a non-fatal error message.

Kind of manual and a pain, but then again this is part of the reason why people are excited to get a volume management redux with BTRFS. Most of the time it’s not really that much of an issue for the reasons derobert mentioned, and because the people who absolutely positively need to ensure continuity of data will usually do RAID and have a backup strategy.

To check the LVM it is done with the following steps.

First we can see our drive layout with lsblk:

# lsblk
NAME                 MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                    8:0    0    20G  0 disk  
└─sda1                 8:1    0    20G  0 part  
  └─xubuntu--vg-root 253:0    0    19G  0 lvm   / 
sr0                   11:0    1  1024M  0 rom   

as we can see the LVM is named xubuntu--vg-root, but we cannot run fsck on this name as it will not find it. We need to get the whole name. To do this we are going to run the lvm lvscan command to get the LV name so we can run fsck on the LVM.

The following commands should be ran as sudo or as a root user.

# lvscan
  inactive          '/dev/xubuntu-vg/root' [<19.04 GiB] inherit
  inactive          '/dev/xubuntu-vg/swap_1' [980.00 MiB] inherit

As we can see our name to check is /dev/xubuntu-vg/root so we should be able to run fsck on that name

If the /dev/xubuntu-vg/root is not ACTIVE, we need to make it active so that we can run the check on it

lvchange -ay /dev/xubuntu-vg/root

Now it should look like this:

# lvscan
  ACTIVE            '/dev/xubuntu-vg/root' [<19.04 GiB] inherit
  inactive          '/dev/xubuntu-vg/swap_1' [980.00 MiB] inherit

Now we can run the fsck on the LVM volume.

fsck /dev/xubuntu-vg/root

or to run a forced check with assume yes

fsck -fy /dev/xubuntu-vg/root

Adding a screen shot since VirtualBox will not let me copy and paste.

Hope this helps!

Добрый день,

Имеется Ubuntu Server и массив LVM2 на трех HDD: 2.0, 1.5, 0.5 ТБ. На каждом из них файловая система XFS. Посыпался один из жестких дисков (тот что на 2.0ТБ). Доступ к массиву еще есть, но примерно 10%-15% файлов уже недоступны. Чтение 80% файлов, существенно медленнее чем ранее (килобайты в секунду), оставшиеся читаются на прежней скорости. Запустить ни long ни short тесты через SMART уже не могу, тесты завершаются с ошибкой не запустившись.

Судя по информации от SMART, диск находится в предсмертном состоянии (1265 bad-блоков на текущий момент).

У меня вопросы:
1) Как можно проверить логическую целостность самого LVM2 массива? Есть утилиты типа fsck для него? vgch не работает, тут же завершается без каких-либо ошибок. xfs_check, xfs_repair тоже выдали что-то несуразное и проверять не стали.
2) Как проверить целостность файловых систем входящих в массив? Для облегчения процесса я купил hdd объемом 4ТБ и сделал pvmove
для дисков 1.5ТБ и 0.5ТБ. Процесс прошел без ошибок. Делать тоже самое для битого опсаюсь-чтобы не отказало все окончательно.
3) Можно ли проверить на бэдблоки в моем случае и купировать такие файлы? Объясняю процесс копирования через mc выглядит так: копируется до проблемного файла: выводит сообщение от ОС об ошибке, если нажать «Пропустить все» — то LVM массив размонтируется, и обратно монтировать приходится вручную. Если нажать «Пропустить» то это приходиться делать для каждого из скольки-то миллионов файлов. Вкупе с крайне медленным чтением- это уже заняло у меня несколько дней. Обычный файловый проводник при открытии папки долго думает, потом вылетает с ошибкой ввода-вывода, после чего массив размонтируется.
4) Безопасно ли сделать pvmove не слетит ли операция при первом же встреченном бэдблоке, оставив массив в промежуточном состоянии?

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

sudo xfs_check /dev/Storage/StorageDrive
ERROR: The filesystem has valuable metadata changes in a log which needs to
be replayed.  Mount the filesystem to replay the log, and unmount it before
re-running xfs_check.  If you are unable to mount the filesystem, then use
the xfs_repair -L option to destroy the log and attempt a repair.
Note that destroying the log may cause corruption — please attempt a mount
of the filesystem before doing this.
localroot@localroot-System-Product-Name:~$
——————————————————————————————-
localroot@localroot-System-Product-Name:~$ sudo xfs_repair /dev/Storage/StorageDrive
Phase 1 — find and verify superblock…
Фаза 2 — использование внутреннего журнала
        — zero log…
ERROR: The filesystem has valuable metadata changes in a log which needs to
be replayed.  Mount the filesystem to replay the log, and unmount it before
re-running xfs_repair.  If you are unable to mount the filesystem, then use
the -L option to destroy the log and attempt a repair.
Note that destroying the log may cause corruption — please attempt a mount
of the filesystem before doing this.
localroot@localroot-System-Product-Name:~$