ZFS deadman

Eugene Grosbein написал(а) к All в Nov 19 15:56:55 по местному времени:

Привет!

У ZFS есть прекрасная фича, называется zfs_deaman.
Она по умолчанию включена на платформах i386 и amd64,
если система выполняется не в качестве гостя в виртуалке.

В госте и на других платформах она по дефолту отключена.
Такой автодетект можно перепопределить в /boot/loader.conf:
если vfs.zfs.deadman_enabled не ноль, то фича включена
(она глобальная для системы) и тогда ZFS периодически
проверяет свою очередь запросов к носителям и если любой
запрос провёл в очереди больше времени, чем vfs.zfs.deadmansynctimems
(1000 секунд по умолчанию), то ZFS считает, что один из носителей
мёртво завис (не то же самое, что возвращает ошибку).

Вместо того, чтобы выкинуть соответствующий носитель из пула
и продолжить работу в деградированном состоянии пула
(что я наблюдал вживую с GEOM_RAID), ZFS паникует систему.

А теперь следим за руками. Чувак берёт машину с 360G памяти,
суёт в неё два 500-гигабайтных SSD под систему и ещё
пять 3.5-терабайтных SSD под RAIDZ1. Начинает жаловаться, что всё тормозит.

Лезем разбираться - ну ещё бы, драйвер контроллера mfi(4)
не поддерживает TRIM как класс. Переделываем на mrsas(4),
выпоняем по-очереди trim всем SSD, скорость взлетает до нормальных значений.

После обновления до 11.3-STABLE система начинает паниковать раз в сутки
или несколько, так как по крону раз в сутки для трех десятков ZVOL
(внутри которых живут виртуалки) выполняется создание новых снапшотов
и удаление старых, а ещё есть то же самое, но почасовое.

Каждый вызов zfs destroy ставит в очередь (в avl_tree на самом деле)
новую пачку запросов ATA TRIM они же ZFSTYPE_FREE, они же BIODELETE.
Операция стирания ячеек SSD - дело не очень быстрое, и если очередь
успела разгрестись за 1000 секунд, то сегодня мы не паникуем.
А не успела - deadman зовёт fm_panic().

ZIL тоже живёт на SSD, ибо других девайсов в системе нет.

Eugene
--
Поэты - страшные люди. У них все святое.
--- slrn/1.0.3 (FreeBSD)