ошибка файловой системы на несуществующем устройстве (ext4_mb_generate_buddy)

Вопрос или проблема

Сервер Ubuntu 20.04 с виртуальными гостевыми серверами.

root@virtual3:/dev# dmesg | grep dm-11
[16067.090601] EXT4-fs (dm-11): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
[16140.884093] EXT4-fs (dm-11): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
[16208.242423] EXT4-fs (dm-11): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
[16280.839903] EXT4-fs (dm-11): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
[16400.942784] EXT4-fs (dm-11): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
[16443.928439] EXT4-fs (dm-11): mounting ext3 file system using the ext4 subsystem
[16443.929427] EXT4-fs (dm-11): warning: mounting fs with errors, running e2fsck is recommended
[16443.934501] EXT4-fs (dm-11): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
[16443.949457] EXT4-fs error (device dm-11): ext4_mb_generate_buddy:1147: group 4, block bitmap and bg descriptor inconsistent: 2731 vs 2732 free clusters
[41267.656921] EXT4-fs (dm-11): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
[41310.767963] EXT4-fs (dm-11): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
[41351.690443] EXT4-fs (dm-11): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
[41393.912918] EXT4-fs (dm-11): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
[41462.134997] EXT4-fs (dm-11): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
[41474.884928] EXT4-fs (dm-11): mounting ext3 file system using the ext4 subsystem
[41474.885747] EXT4-fs (dm-11): warning: mounting fs with errors, running e2fsck is recommended
[41474.890554] EXT4-fs (dm-11): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
[41474.904432] EXT4-fs error (device dm-11): ext4_mb_generate_buddy:1147: group 4, block bitmap and bg descriptor inconsistent: 2731 vs 2732 free clusters

root@virtual3:/dev# ls dm*
dm-0  dm-1  dm-10  dm-2  dm-3  dm-4  dm-5  dm-6  dm-7  dm-8  dm-9

Как видно, нет /dev/dm-11, поэтому я не уверен, что делать дальше. Корневой диск – SSD (содержит dm-0 до dm-8), и также есть обычный HDD (на котором dm-9 и dm-10).

Система выдала ошибку с загадочной проблемой сети, которая разрешилась магическим образом (т.е. путем перезапуска systemd-networkd несколько раз) – я еще не понял, как и не смог найти ничего в журналах. Не знаю, связаны ли две проблемы.

На момент написания этого, кажется, все работает. smartctl не сообщает об ошибках.

#!/bin/bash

# Функция для запуска e2fsck на всех логических томах
run_e2fsck() {
  echo "Запуск e2fsck на всех логических томах..."
  for lv in $(lvdisplay | grep "LV Path" | awk '{print $3}'); do
    echo "Проверка файловой системы на $lv..."
    # Используйте -n для пробного запуска, чтобы увидеть, что будет сделано без изменений
    e2fsck -n $lv
    # Если вы уверены, удалите -n для фактического исправления проблем, но будьте осторожны
    # e2fsck -f $lv
  done
}

# Проверка состояния LVM
echo "Проверка состояния LVM..."
lvscan
lvdisplay

# Попытка активировать все логические тома
echo "Активация всех логических томов..."
lvchange -ay

# Специфическая проверка для dm-11
if ls /dev/dm-* | grep -q "dm-11"; then
  echo "dm-11 существует, запуск e2fsck на нем..."
  e2fsck -n /dev/dm-11
else
  echo "dm-11 не существует или не активен."
fi

# Проверка состояния оборудования
echo "Проверка состояния оборудования..."
for device in /dev/sd[a-z]; do
  if [ -e "$device" ]; then
    echo "Запуск smartctl на $device..."
    smartctl -a $device
  fi
done

# Настройка логирования systemd-networkd (опционально, для будущих сетевых проблем)
echo "Установка systemd-networkd на ведение детализированного журнала..."
sudo mkdir -p /etc/systemd/system/systemd-networkd.service.d/
echo -e "[Service]\nEnvironment=SYSTEMD_LOG_LEVEL=debug" | sudo tee /etc/systemd/system/systemd-networkd.service.d/override.conf
sudo systemctl daemon-reload
sudo systemctl restart systemd-networkd

# Мониторинг системных журналов на предмет новых ошибок (запустите это на некоторое время)
echo "Мониторинг системных журналов на предмет новых ошибок. Нажмите Ctrl+C для остановки."
journalctl -f

# Предложение по резервному копированию
echo "Не забывайте регулярно делать резервные копии всех критических данных."

# Примечание: Этот скрипт не включает команды для реальной манипуляции данными или их восстановления из-за связанных рисков. 
# Он предназначен для диагностических целей. Если решите запускать e2fsck без -n, убедитесь, что понимаете последствия.

Ответ или решение

Разбор ошибки файловой системы на несуществующем устройстве (ext4_mb_generate_buddy)

Теория

В вашем случае система Ubuntu 20.04 на сервере столкнулась с ошибками файловой системы EXT4, как показывает лог сообщений dmesg. Основная проблема заключается в несовпадении битовой карты блоков и описателей блоков для группы 4, что выражается в разнице между количеством свободных кластеров: 2731 против 2732. Это может указывать на повреждение структуры файловой системы, вероятно, вызванное аппаратной проблемой, внезапным отключением питания или некорректным завершением работы.

Пример

В предоставленных логах видно частое монтирование файловой системы на устройстве dm-11 с предупреждением о наличии ошибок и рекомендацией использовать e2fsck. Это утилита для проверки и исправления ошибок в файловых системах EXT2, EXT3 и EXT4. Однако проблема возникает в том, что устройство dm-11 не отображается в списке /dev, что усложняет диагностику и исправление.

Применение

Чтобы решить проблему, нужно предпринять следующие шаги:

  1. Проверка устройств и логических томов: Убедитесь, что все логические тома активированы и выявлено расположение dm-11. Сначала выполните команду lvscan для отображения всех логических томов и их статус. Затем активируйте их с помощью lvchange -ay.

  2. Запуск e2fsck: Если dm-11 станет доступным, выполните e2fsck -n /dev/dm-11 для безопасной проверки на наличие ошибок. Если ошибки будут найдены и вы уверены в своих действиях, можно запустить e2fsck -f без ключа -n для исправления проблем. Однако заранее создайте резервные копии, чтобы предотвратить потерю данных.

  3. Диагностика оборудования: Используйте утилиту smartctl для диагностики состояния дисков SSD и HDD. Это поможет выявить аппаратные проблемы, которые могут быть причиной ошибок файловой системы.

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

  5. Мониторинг системы: Следите за логами в реальном времени через journalctl -f, чтобы оперативно отреагировать на появление новых ошибок.

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

Оцените материал
Добавить комментарий

Капча загружается...