Linux kernel 5.15 LTS и NTFS3: переводим серверный образ и наконец чиним Samba на NTFS

Linux kernel 5.15 получил статус LTS в середине ноября. Это тот момент, когда мы начинаем готовить обновление базового образа - для новых серверов и для планового обновления действующих. На этот раз поводов несколько, и один из них конкретно закрывает давнюю проблему с производительностью, которую мы видели на нескольких клиентских стендах.

Что интересного в 5.15

По-быстрому по списку:

• NTFS3 driver от Paragon. Полноценный kernel-level драйвер чтения и записи NTFS, который Paragon передал в upstream. Не ntfs-3g в FUSE-пространстве, а настоящий kernel module. Это принципиальное отличие.
• AF_XDP расширения. Дополнительные возможности для zero-copy обработки пакетов - актуально для тех, кто строит software-defined networking или занимается high-performance packet processing через XDP.
• BPF subsystem. Доработки BPF verifier, новые helper-функции, улучшения в BPF Type Format (BTF) - продолжение большой работы по расширению возможностей eBPF.
• WQ_SYSFS for workqueues. Более точный контроль над kernel workqueue через sysfs - нишевая вещь, но иногда спасает при отладке проблем с CPU affinity на NUMA-системах.

Нас на практике интересует в первую очередь NTFS3. AF_XDP и BPF для текущих клиентских задач - фоновое улучшение, которое будет полезно через инструменты типа cilium или при использовании nftables с BPF-бэкендом, но это не немедленный операционный повод.

Застарелая проблема с NTFS на Samba

На двух клиентских стендах у нас стоят Linux-серверы с Samba, где данные лежат на NTFS-томах. Исторически так сложилось - тома приехали с Windows-серверов при переходе на Linux, перекладывать терабайты данных никто не планировал, проще было примонтировать как есть.

Проблема известная: ntfs-3g работает в FUSE (Filesystem in Userspace). Каждая файловая операция совершает переход между kernel space и user space - это overhead, который заметен на интенсивном IO. На Samba-сервере с несколькими десятками одновременных подключений этот overhead накапливается и превращается в задержки, которые пользователи видят как «тормозит файлопомойка». Особенно неприятно на мелкочастотных операциях - открытие каталогов с большим количеством файлов, частое открытие и закрытие небольших документов.

Мы это видели в мониторинге: iowait держался выше нормы не потому что диски не справляются, а потому что FUSE добавлял переключения контекста. На хороших SSD это особенно обидно - железо быстрое, а файловый стек создаёт искусственный потолок.

NTFS3: что меняется

NTFS3 работает как полноценный kernel driver - без FUSE-прослойки. Запрос от Samba идёт в VFS, дальше - напрямую в kernel module, и всё что связано с переключением контекста между kernel и user space исчезает.

Парагон работал над этим driver долго - первые patches появились ещё в начале 2021, прошли несколько раундов review в lkml. В 5.15 это уже готовая, смержённая реализация.

Монтирование прямолинейное:

mount -t ntfs3 /dev/sdb1 /mnt/data

Или в fstab:

/dev/sdb1  /mnt/data  ntfs3  defaults,uid=samba,gid=samba  0  0

Если раньше стоял ntfs-3g - меняем тип на ntfs3, убираем fuse.ntfs-3g из mount options. На системах с systemd нужно убедиться что ntfs3.ko загружается через modules-load.d или добавляется в initramfs если том монтируется при загрузке.

Как мы обновляемся

Базовый образ у нас на Rocky Linux 8 - собирали его летом под клиентские задачи. Rocky 8 поставляется с kernel 4.18 из RHEL-базы - это LTS ветка с backported-патчами, но NTFS3 туда не прилетит: feature-freeze для 4.18 давно прошёл.

Для того чтобы получить 5.15 на Rocky 8 без сборки из исходников, используем ELRepo - там есть kernel-ml channel:

rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
dnf install https://www.elrepo.org/elrepo-release-8.el8.elrepo.noarch.rpm
dnf --enablerepo=elrepo-kernel install kernel-ml

ELRepo поставляет mainline kernel собранный под EL8. На продакшене это требует тестирования - часть kernel modules может быть несовместима, DKMS-модули потребуют пересборки. У нас в первую очередь нужно проверить kmod для мониторинга (Zabbix-агент с некоторыми kernel-модулями) и любые DKMS-пакеты если они есть.

Процесс на стенде перед продакшеном:

1. Ставим kernel-ml рядом с основным kernel - GRUB покажет оба варианта.
2. Загружаемся в 5.15, проверяем что все сервисы поднялись.
3. Перемонтируем NTFS-тома через ntfs3, прогоняем нагрузку.
4. Смотрим на iowait и latency в сравнении с ntfs-3g.

На стенде разница по iowait на Samba-нагрузке ощутимая - FUSE-overhead уходит. Насколько это выразится в реальном user experience на конкретном клиентском стенде - посмотрим при пилоте, не хотим давать цифры раньше времени.

Что с BPF и AF_XDP

AF_XDP в 5.15 получил поддержку multi-buffer - это позволяет обрабатывать jumbo-фреймы и scatter-gather сценарии в zero-copy режиме. Для XDP-based load balancer или packet filter это важно. На наших текущих клиентских задачах AF_XDP напрямую не применяется, но мы смотрим в сторону cilium на kubernetes-кластерах - и там это будет задействовано.

BPF-улучшения в 5.15 - это в основном developer experience: лучший verifier с более понятными сообщениями об ошибках, дополнительные BTF-аннотации для kernel structures. Практически это проявится в более удобной отладке BPF programs и чуть более быстрой разработке кастомных XDP/TC hooks.

Текущий статус

Образ с kernel 5.15 собрали и прогоняем на внутреннем стенде. На клиентский пилот планируем выкатить в декабре на одном из Samba-серверов с NTFS-томами - это наименее рискованный способ проверить NTFS3 в условиях реальной нагрузки перед массовым переходом.

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