🐧 Linux: Ядро 7.0 вышло — и вот что из этого реально важно для продакшна

Коллеги, пока одни спорили о нумерации, 12 апреля 2026 года тихо вышел Linux 7.0. Сам Линус объяснил переход с 6.x: это просто сброс счётчика после того, как минорная версия добралась до 19 — никакой революции, обычный релиз на круглом номере. Но внутри есть вещи, которые прямо касаются нас.

Три изменения, за которыми стоит следить:

Первое — XFS научился самовосстанавливаться. XFS теперь может обнаруживать повреждения метаданных во время работы и исправлять их без размонтирования тома. Если вы держите XFS под базами или критическими данными — это означает меньше окон обслуживания и меньше xfs_repair в 4 утра.

Второе — Rust официально стабилен в ядре. С 7.0 снят experimental-тег с поддержки Rust, и язык теперь официально разрешён для разработки модулей ядра. Для нас как администраторов это сигнал: новые драйверы и модули безопасности будут всё чаще писаться на Rust, а значит — меньше memory corruption в сторонних модулях долгосрочно.

Третье — подписи модулей на постквантовой криптографии. Добавлена поддержка ML-DSA для аутентификации модулей ядра, а поддержка SHA-1 для подписи модулей удалена. Если у вас кастомные или DKMS-модули подписаны старыми ключами — время проверить и пересобрать.

Как проверить, что вы не сломаетесь при переходе:

# Смотрим текущую версию и параметры компиляции
uname -r
cat /boot/config-$(uname -r) | grep -E "CONFIG_MODULE_SIG|CONFIG_RUST"

# Проверяем подписи установленных DKMS-модулей
dkms status
# Все модули должны пересобраться под новое ядро автоматически

# Для XFS — проверяем здоровье до обновления (на всякий случай)
xfs_info /dev/sda1
dmesg | grep -i xfs | grep -iE "error|corrupt|repair"

# После перехода на 7.0 — смотрим, что новый самохил XFS активен
dmesg | grep -i "xfs.*repair\|xfs.*heal"

# Ubuntu 26.04 LTS получит 7.0 из коробки (выход 23 апреля)
# На текущих системах — через mainline PPA для тестирования:
sudo add-apt-repository ppa:kernel-ppa/mainline
sudo apt update && apt list --upgradable | grep linux-image

Зачем это нужно:
Linux 7.0 станет ядром по умолчанию в Ubuntu 26.04 LTS и Fedora 44 — а это означает, что большинство корпоративных образов виртуальных машин через квартал-два будут именно на нём. Лучше понять изменения сейчас в лабе, чем разбираться с ними в продакшне.

Итог: XFS-самовосстановление и постквантовые подписи модулей — не хайп. Это инфраструктурные изменения, которые через год будут в каждом энтерпрайз-образе. Читайте changelog, а не только твиттер.

#linux #kernel #xfs #security #sysadmin #admin_future

🐧 Linux: XFS self-healing в ядре 7.0 — конец ночных xfs_repair на продакшне

Коллеги, 12 апреля вышел Linux 7.0, и пока все обсуждают красивый мажорный номер версии и официальный статус Rust, кое-что поважнее тихо проскользнуло мимо радаров большинства. Для тех, кто держит боевые серверы на XFS — а это весь RHEL-мир, CentOS-наследники, Rocky и Alma — это прямой удар по одной из самых болезненных ситуаций в практике.

До 7.0 картина была такая: если XFS обнаруживал повреждение метаданных — от скачка питания, аппаратного сбоя или битого сектора — файловая система переходила в read-only или падала с ошибкой. Требовалось размонтировать том, часто невозможное на живой корневой ФС, загрузиться с rescue-медиа и запустить xfs_repair вручную.

Теперь другая история. Новая возможность использует специальный daemon, который опирается на parent pointer metadata и reverse mapping для обнаружения ошибок, о которых сообщает ядро, и запускает исправление автоматически. Всё это происходит пока файловая система примонтирована и активно используется.

Важный нюанс сразу: ядро не сканирует файловую систему непрерывно. Вместо этого — когда при обычных операциях чтения или записи встречаются несогласованные метаданные, оно теперь пытается исправить их на месте, а не возвращать ошибку или переходить в read-only. Это не покрывает все сценарии: глубокие структурные повреждения, аппаратный bit rot и сбои в блоках данных по-прежнему требуют офлайн-ремонта или восстановления из бэкапа.

Что делать практически прямо сейчас:

# Проверяем версию ядра — нужна 7.0+
uname -r

# На Ubuntu 26.04 LTS (выходит 23 апреля) — будет из коробки
# На текущих системах — смотрим в mainline PPA для тестовых сред:
# add-apt-repository ppa:kernel-ppa/mainline && apt update

# Проверяем что XFS примонтирован с нужными опциями
# self-healing включён по умолчанию — дополнительной конфигурации не нужно
mount | grep xfs
# Убеждаемся что есть rmapbt и parent pointers (нужны для self-heal)
xfs_info /dev/sda1 | grep -E "rmapbt|ftype|reflink"

# Мониторинг self-healing активности в реальном времени
# Смотрим dmesg — ядро будет логировать каждое исправление
dmesg -w | grep -iE "xfs.*(heal|repair|corrupt|recover)"

# Пример того что увидим при срабатывании:
# [ 183.44] XFS (sda1): Repairing corrupt inode btree in AG 2.
# [ 183.45] XFS (sda1): Self-healing complete. Filesystem operational.

# Для мониторинга через journalctl (если нет dmesg watch):
journalctl -k -f | grep -i "xfs"

# Проверяем health XFS-тома утилитой xfs_scrub (рекомендуется периодически)
# В режиме онлайн — не блокирует работу
xfs_scrub -v /mount/point

# Настраиваем регулярный xfs_scrub через systemd timer (уже есть в xfsprogs)
systemctl enable --now xfs_scrub_all.timer
systemctl status xfs_scrub_all.timer

# Смотрим статистику ошибок ФС
xfs_db -r -c "check" /dev/sda1  # offline check для диагностики

Зачем это нужно:
Для системных администраторов, отвечающих за XFS-тома на продакшн-серверах, это значимое улучшение quality-of-life. Однако эту возможность не следует использовать как замену полноценному процессу резервного копирования и восстановления. Self-healing — это safety net для конкретного класса сбоев, а не страховка от всего.

Итог: xfs_repair в 3 ночи с rescue USB — это был обряд посвящения для каждого линукс-администратора. В ядре 7.0 этот обряд стал значительно реже встречаться. Бэкапы всё равно делайте.

#linux #xfs #kernel7 #storage #filesystem #sysadmin #admin_future