Архитектура высокой производительности XFS и механизм журналирования

Файловая система XFS — это высокомасштабируемая 64-битная журналируемая файловая система, разбивающая дисковое пространство на независимые группы выделения (Allocation Groups, AG), каждая из которых содержит свои B+ деревья свободного пространства, инодов и экстентов. XFS использует упреждающее журналирование метаданных (Metadata Journaling). При внезапных отключениях электропитания или дисковых ошибках ядро Linux блокирует монтирование XFS для предотвращения разрушения структур:

• XFS (sda2): Metadata corruption detected at ...
• XFS (sda2): Filesystem has duplicate UUID ... - can't mount
• XFS (sda2): Corruption of in-memory data detected. Shutting down filesystem
• mount: mount /dev/sda2 on /data failed: Structure needs cleaning (Системная ошибка EFSCORRUPTED / EUCLEAN).

Бизнес-риски

Отказ Enterprise-дистрибутивов (RHEL, Rocky Linux, AlmaLinux, CentOS, где XFS является файловой системой по умолчанию), блокировка баз данных PostgreSQL/MongoDB.

Сравнение инструментов обслуживания XFS и EXT4

Регламент восстановления файловой системы XFS

Сценарий 1: Размонтирование файловой системы

Внимание: xfs_repair категорически запрещено запускать на смонтированном разделе!

# Размонтирование раздела:
sudo umount /dev/sda2

# Если это корневой раздел -> загрузитесь с Rescue LiveCD или в аварийном режиме Emergency Mode.

Сценарий 2: Анализ журнала транзакций через xfs_logprint

# Проверка состояния журнала на предмет незавершенных «грязных» транзакций:
sudo xfs_logprint /dev/sda2

# Если журнал содержит нормальные транзакции, стандартное монтирование автоматически выполнит Log Replay (восстановление метаданных):
sudo mount -o loop /dev/sda2 /mnt && sudo umount /mnt

Сценарий 3: Запуск восстановления целостности утилитой xfs_repair (Dry-Run и Repair)

# 1. Запуск безопасной проверки БЕЗ внесения изменений (Dry-run mode):
sudo xfs_repair -n /dev/sda2

# 2. Штатный запуск восстановления структур и B+ деревьев:
sudo xfs_repair -v /dev/sda2

Сценарий 4: Экстренное обнуление поврежденного журнала (xfs_repair -L)

Если журнал транзакций поврежден физически и xfs_repair возвращает ошибку:
«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», а смонтировать раздел невозможно:

# ВНИМАНИЕ: Флаг -L (Force Log Zeroing) принудительно обнуляет журнал транзакций!
# Это может привести к потере последних незафиксированных метаданных, но позволяет восстановить саму ФС!

sudo xfs_repair -L -v /dev/sda2

# После успешного завершения смонтируйте файловую систему:
sudo mount /dev/sda2 /mnt

Сценарий 5: Исправление ошибки дублирования UUID при клонировании дисков

Если диск был скопирован через dd и XFS отказывается монтироваться из-за одинакового UUID с существующим диском:

# Генерация нового случайного UUID для раздела XFS:
sudo xfs_admin -U generate /dev/sda2

Типовые ошибки администраторов

• Попытка использовать fsck.xfs: В дистрибутивах Linux скрипт fsck.xfs является заглушкой, которая всегда возвращает статус 0 (Success). Реальный ремонт выполняет ТОЛЬКО утилита xfs_repair.
• Применение xfs_repair -L без предварительной попытки смонтировать раздел: Обнуление лога уничтожает самые свежие транзакции, которые могли быть успешно применены штатным драйвером ядра при стандартном монтировании.