ZFS autotrim: Збереження швидкості SSD-пулів з часом

SSD швидкі, доти поки перестають бути такими. Не катастрофічно, не з голосними помилками — просто поступово повільніші, з більшою мінливістю затримок та дивною непостійністю під навантаженнями, насиченими записами. У світі ZFS це відчуття «SSD старіє» часто означає, що шар трансляції флеш-пам’яті (FTL) пристрою вичерпує прості рішення, бо він не знає, які блоки вам більше не потрібні.

TRIM — це спосіб сказати SSD: «Ці блоки вільні; можете використовувати їх знову у будь-який час». ZFS autotrim — це виробничо-дружній спосіб підтримувати цю розмову постійно, без перетворення вашої команди зберігання на культ уікендових пакетних завдань. У цій статті пояснюється, що насправді робить autotrim, чого він не робить, і як безпечно запускати його, коли ваш пул — серце бізнесу, який очікує, що час без відмов буде нудним.

Що таке autotrim (і чим він не є)

Autotrim у ZFS — це безперервний TRIM. Коли ZFS звільняє блоки — тому що ви видалили дані, перезаписали їх, знищили снапшот або блок був переміщений — autotrim може передати підсистемі повідомлення на кшталт «ці LBA більше не використовуються» вниз до SSD. SSD тоді може проактивно стерти флеш-блоки у фоновому режимі, щоб наступні записи не платили «податок за збір сміття» у найгірший можливий момент.

Autotrim не є дефрагментатором. Він не зробить ваш пул більш суміжним або не зіллє старі дані в один шматок. Також він не відновлює простір «чарівним» способом; ZFS і так знає про свій вільний простір. TRIM стосується внутрішнього обслуговування пристрою і коефіцієнту множення записів, а не обліку в ZFS.

Autotrim також не замінює правильного розміру та overprovisioning. Якщо ваш пул зайнятий на 95%, autotrim — це як ввічливо просити ліфт їхати швидше, поки ви продовжуєте намагатися вмістити в нього ще людей. Ліфт все одно зупинятиметься на кожному поверсі.

Короткий жарт, бо зі зберіганням потрібні механізми виживання: TRIM — це по суті сказати SSD «це не ти, це я». На жаль, SSD все одно все пам’ятає — просто повільніше, коли його ображають.

Реальність SSD, з якою працює ZFS

SSD не перезаписують дані на місці. Флеш-сторінки записуються, але стирання відбувається на більшій границі (erase blocks). Коли ви «перезаписуєте» LBA, SSD зазвичай записує нові дані в інше місце та позначає стару фізичну локацію як застарілу. Пізніше збір сміття консолідує дійсні сторінки та стирає старі блоки, щоб їх можна було повторно використовувати. Саме тут з’являється write amplification: ви записали 4 KB, а SSD довелося перемістити 256 KB даних, щоб почистити блок.

TRIM допомагає тим, що зменшує обсяг «можливо ще дійсних» даних, які SSD має зберігати під час збору сміття. Якщо SSD знає, що діапазон не використовується, він може одразу його ігнорувати. Це часто означає меншу варіативність затримок і кращу тривалу продуктивність запису, особливо після довгих періодів інтенсивних змін.

У корпоративній експлуатації варіативність затримок — вбивця. Середні значення вас не розбудять. Хвостова затримка розбудить вас о 02:13 з напівзавантаженою панеллю Grafana і командою бази даних, яка раптом згадала ваше ім’я.

Цікаві факти та історичний контекст

• TRIM з’явився як стандартизована команда ATA наприкінці 2000-х, коли SSD почали показувати поведінку «швидкий з коробки, через шість місяців… хмм» під навантаженнями настільних систем.
• NVMe використовує «Dataset Management» (deallocate), а не ATA TRIM, але намір той самий: повідомити контролеру про невикористовувані LBA для оптимізації.
• Ранні прошивки SSD часто ігнорували TRIM або реалізовували його погано, тому старожили досі здригаються, коли ви кажете «просто увімкніть discard».
• ZFS спочатку орієнтувався на диски, де перезаписи були дешевими і де «знання про вільний простір» переважно було питанням ОС, а не пристрою.
• Файлові системи з copy-on-write (ZFS, btrfs) змінюють історію TRIM, оскільки звільнення відбуваються пачками (знищення снапшотів, коміти транзакцій), а не як у місцевих перезаписах.
• Деякі RAID-контролери раніше блокували або неправильно обробляли TRIM, особливо апаратний RAID поверх SATA. Сучасні HBA в IT-режимі зазвичай значно безпечніші для ZFS.
• Тонке провізіонування в SAN має подібну концепцію: потрібен «UNMAP»/discard, щоб повертати звільнені блоки назад масиву; без нього масив залишається «повним» назавжди.
• «Secure erase» — це не TRIM; secure erase — це руйнівна операція типу скидання, тоді як TRIM — це підказка про невикористовуваний простір.

Як внутрішньо працює ZFS TRIM/autotrim

ZFS відслідковує розподіли на рівні пулу у метаслабах. Коли блоки звільняються, вони переходять з allocated у free у погляді ZFS. Autotrim додає другий крок: він відправляє TRIM/deallocate для цих діапазонів підлеглим vdev.

Існує два операційні моделі, які ви побачите:

• Безперервний autotrim: увімкнений на рівні пулу, тому звільнення тригерять підказки TRIM з часом.
• Ручний «zpool trim»: явна фонова операція, яка проходить карти вільного простору й видає trim для вільних регіонів; корисно після імпорту пулу, після великого видалення чи при пізньому ввімкненні autotrim.

Важлива тонкість: ZFS не завжди може ідеально обрізати великі суміжні ділянки, бо алокації можуть бути перемішані та через те, як карти простору записують історичні алокації. Також занадто агресивний trim може конкурувати з реальним I/O. Як і в усьому, у зберіганні це компроміс між «зробити роботу зараз, щоб уникнути її пізніше» і «будь ласка, не роби роботу, коли мої бази даних пишуть».

Другий жарт, бо ми всі його заслужили: Увімкнути autotrim на зайнятому пулі й одразу запускати бенчмарки — це як мітити кухню під час прийому гостей: технічно продуктивно, соціально катастрофічно.

Увімкнення, перевірка та спостереження за autotrim

Перше питання в продакшні не «чи можна його увімкнути?» — а «що ще воно торкнеться?». Autotrim зачіпає шар пристрою й може змінити I/O-патерни, особливо на SATA SSD з обмеженими чергами або на системах, де операції discard серіалізуються за іншими командами.

Сучасний NVMe зазвичай поводиться з deallocate менш драматично, але «зазвичай» — не те ж саме, що «гарантовано». Правильний підхід: увімкнути autotrim, спостерігати за затримками та завантаженням пристроїв і бути готовим відкотитися або запланувати ручні trim-процедури при необхідності.

Також: підтвердіть, що весь шлях підтримує це. Прошивка диска, транспорт (SATA/SAS/NVMe), режим контролера та драйвер ОС — все має значення. Якщо ви на віртуальній платформі й «SSD» — це віртуальний диск, TRIM може загубитися на рівні гіпервізора.

Практичні завдання: команди + інтерпретація

Нижче наведені виробничого рівня завдання, які я насправді виконую (або хотів би виконати раніше). Команди показані для Linux з OpenZFS і вони реалістичні; адаптуйте імена пристроїв і пулів відповідно.

Task 1: Identify pools and vdevs (baseline inventory)

cr0x@server:~$ sudo zpool list
NAME    SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
tank   7.25T  3.90T  3.35T        -         -    18%    53%  1.00x  ONLINE  -

cr0x@server:~$ sudo zpool status -v tank
  pool: tank
 state: ONLINE
config:

        NAME                                    STATE     READ WRITE CKSUM
        tank                                    ONLINE       0     0     0
          mirror-0                              ONLINE       0     0     0
            nvme-SAMSUNG_MZVLB1T0HBLR-00000_1    ONLINE       0     0     0
            nvme-SAMSUNG_MZVLB1T0HBLR-00000_2    ONLINE       0     0     0

Інтерпретація: Знати, що ви обрізаєте. Дзеркала і RAIDZ поводяться по-різному під тиском; також переконайтеся, що ви дійсно на SSD/NVMe, а не в міксі з несподіваним SATA-пристроєм.

Task 2: Check whether the pool has autotrim enabled

cr0x@server:~$ sudo zpool get autotrim tank
NAME  PROPERTY  VALUE     SOURCE
tank  autotrim  off       default

Інтерпретація: off означає, що ZFS не буде безперервно відправляти підказки TRIM при звільненнях. Це не означає, що SSD приречений — це просто означає, що система більше покладається на внутрішні евристики та будь-який періодичний ручний trim.

Task 3: Enable autotrim (and record the change)

cr0x@server:~$ sudo zpool set autotrim=on tank
cr0x@server:~$ sudo zpool get autotrim tank
NAME  PROPERTY  VALUE  SOURCE
tank  autotrim  on     local

Інтерпретація: Це зміна в реальному часі. Спостерігайте за затримками та завантаженням пристроїв деякий час, особливо якщо пул зайнятий або майже повний.

Task 4: Run a one-time trim pass (useful after enabling late)

cr0x@server:~$ sudo zpool trim tank
cr0x@server:~$ sudo zpool status -t tank
  pool: tank
 state: ONLINE
  scan: trim in progress since Thu Dec 21 02:11:54 2025
        1.20T trimmed, 22.3% done, 0:36:18 to go
config:

        NAME                                    STATE     READ WRITE CKSUM
        tank                                    ONLINE       0     0     0
          mirror-0                              ONLINE       0     0     0
            nvme-SAMSUNG_MZVLB1T0HBLR-00000_1    ONLINE       0     0     0
            nvme-SAMSUNG_MZVLB1T0HBLR-00000_2    ONLINE       0     0     0

Інтерпретація: Ручний trim — це фонове заняття (схоже по духу на scrub/resilver звіти). Він все ще може конкурувати з навантаженням. Розглядайте його як операційну подію: плануйте, спостерігайте та зупиняйте, якщо шкодить.

Task 5: Pause or stop an in-progress trim (when it hurts)

cr0x@server:~$ sudo zpool trim -s tank
cr0x@server:~$ sudo zpool status -t tank
  pool: tank
 state: ONLINE
  scan: trim stopped since Thu Dec 21 02:51:09 2025
        1.34T trimmed, 24.9% done

Інтерпретація: Зупинка trim не є збоєм. Це контроль. Коли робоче навантаження страждає, ви призупиняєте фоні роботи й повертаєтесь пізніше.

Task 6: Confirm the device advertises discard/TRIM support (SATA/SCSI path)

cr0x@server:~$ lsblk -D
NAME         DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
nvme0n1             0      512B       2T         0
nvme1n1             0      512B       2T         0

Інтерпретація: Непорожні поля discard granularity/max — добрий знак. Якщо ці поля нульові на SSD, discard може бути заблокований стеком (контролер, драйвер, віртуалізація).

Task 7: Verify NVMe deallocate capabilities (NVMe devices)

cr0x@server:~$ sudo nvme id-ctrl /dev/nvme0 | sed -n '1,80p'
vid     : 0x144d
ssvid   : 0x144d
sn      : S4X9NF0M123456
mn      : SAMSUNG MZVLB1T0HBLR-00000
fr      : EXA7301Q
...
oncs    : 0x001f
...

Інтерпретація: Можливості контролера залежать від моделі/прошивки. Ви шукаєте підтримку функцій управління наборами даних у стеку й хочете актуальну прошивку, бо «quirks» NVMe реальні.

Task 8: Watch pool-level latency and throughput during trim

cr0x@server:~$ sudo zpool iostat -v tank 1
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        3.90T  3.35T    122    410  26.1M  71.4M
  mirror    3.90T  3.35T    122    410  26.1M  71.4M
    nvme0n1     -      -     61    210  13.0M  36.2M
    nvme1n1     -      -     61    200  13.1M  35.2M

Інтерпретація: Це ваша перша перевірка «чи шкодить це?». Якщо операції запису зростають, але пропускна здатність не росте, або якщо час відповіді сплескує (див. наступні завдання), trim може боротися з вашим навантаженням.

Task 9: Observe per-disk latency and queueing with iostat

cr0x@server:~$ iostat -x 1
Linux 6.6.0 (server) 	12/25/2025 	_x86_64_	(32 CPU)

Device            r/s     w/s   rMB/s   wMB/s  await  aqu-sz  %util
nvme0n1         62.0   215.0    13.2    36.7   2.10    0.65   58.0
nvme1n1         61.0   205.0    13.0    35.9   2.05    0.61   56.9

Інтерпретація: На NVMe await в низьких однозначних мілісекундах під навантаженням часто прийнятний; сплески в десятки мс — це те, де додатки починають «відчувати привид». Для SATA SSD вищі числа можуть бути нормальними, але важливим є тренд.

Task 10: Check dataset properties that influence churn (recordsize, atime, sync)

cr0x@server:~$ sudo zfs get -o name,property,value,source recordsize,atime,sync tank
NAME  PROPERTY    VALUE   SOURCE
tank  recordsize  128K    default
tank  atime       off     local
tank  sync        standard default

Інтерпретація: TRIM не виправить патологічне «churn». Якщо датасет VM використовує recordsize, що спричинює постійне перевитрачання записів, autotrim буде зайнятий очищенням наслідків.

Task 11: Determine how full and fragmented the pool is

cr0x@server:~$ sudo zpool list -o name,size,alloc,free,cap,frag,health
NAME  SIZE  ALLOC  FREE  CAP  FRAG  HEALTH
tank  7.25T  3.90T 3.35T 53%  18%   ONLINE

Інтерпретація: Високі CAP і FRAG часто корелюють з погіршенням продуктивності з часом. TRIM допомагає SSD, але не створює суміжні вільні метаслаби в ZFS. Нудне виправлення може бути «додати vdev» або «не працювати при 90% заповненості».

Task 12: Check snapshot pressure (a hidden TRIM limiter)

cr0x@server:~$ sudo zfs list -t snapshot -o name,used,refer,creation -S used | head
NAME                          USED  REFER  CREATION
tank/db@hourly-2025-12-25-0200  98G  1.20T  Thu Dec 25 02:00 2025
tank/db@hourly-2025-12-25-0100  96G  1.19T  Thu Dec 25 01:00 2025
tank/db@hourly-2025-12-25-0000  95G  1.18T  Thu Dec 25 00:00 2025

Інтерпретація: Якщо снапшоти закріплюють старі блоки, видалення фактично не звільняє простір. Це означає менше можливостей для TRIM і більше старого сміття, що висить на SSD.

Task 13: Measure actual free space inside a thin-provisioned zvol (VM disks)

cr0x@server:~$ sudo zfs get -o name,property,value,source volblocksize,refreservation,compressratio tank/vm-100-disk-0
NAME                 PROPERTY       VALUE  SOURCE
tank/vm-100-disk-0    volblocksize   16K    local
tank/vm-100-disk-0    refreservation none   default
tank/vm-100-disk-0    compressratio  1.35x  -

cr0x@server:~$ sudo zfs list -o name,used,logicalused,volsize tank/vm-100-disk-0
NAME                 USED  LOGICALUSED  VOLSIZE
tank/vm-100-disk-0   420G  760G         800G

Інтерпретація: Гостьова ОС може видаляти дані, але без проходження discard від гостя → гіпервізора → zvol → пул → SSD основний пристрій ніколи не дізнається, що ці блоки вільні. Autotrim допомагає, коли ZFS знає, що блоки звільнені; він не може вгадати наміри гостя.

Task 14: Check whether compression is helping reduce churn

cr0x@server:~$ sudo zfs get -o name,property,value,source compression,compressratio tank
NAME  PROPERTY      VALUE     SOURCE
tank  compression   lz4       local
tank  compressratio 1.52x     -

Інтерпретація: Менший обсяг фізичних записів часто означає менше тиску на збір сміття. Стиснення не замінює TRIM, але зменшує обсяг роботи, з якою TRIM намагається впоратися.

Task 15: Validate that “freeing space” actually trims over time (operational observation)

cr0x@server:~$ sudo zfs destroy tank/tmp@old-bulk-delete
cr0x@server:~$ sudo zpool status -t tank
  pool: tank
 state: ONLINE
  scan: trim in progress since Thu Dec 25 03:05:41 2025
        220G trimmed, 6.4% done, 1:12:44 to go

Інтерпретація: Великі знищення снапшотів можуть тригерити багато звільнень, що може спричинити багато trim-дій. Якщо ваше навантаження чутливе, плануйте великі зміни ретеншену так само, як міграції схеми бази даних.

Task 16: Prove the stack isn’t hiding discard (sanity check with a small scratch pool)

cr0x@server:~$ sudo zpool create -o ashift=12 trimtest /dev/nvme2n1
cr0x@server:~$ sudo zpool set autotrim=on trimtest
cr0x@server:~$ sudo zfs create -o compression=off trimtest/scratch
cr0x@server:~$ sudo dd if=/dev/zero of=/trimtest/scratch/bigfile bs=1M count=2048 oflag=direct status=progress
2147483648 bytes (2.1 GB, 2.0 GiB) copied, 5 s, 429 MB/s
cr0x@server:~$ sudo rm /trimtest/scratch/bigfile
cr0x@server:~$ sudo zpool status -t trimtest
  pool: trimtest
 state: ONLINE
  scan: trim in progress since Thu Dec 25 03:22:10 2025
        2.00G trimmed, 100% done, 0:00:00

Інтерпретація: Це не доводить, що кожен шар ідеальний, але виявляє очевидні ситуації, коли discard — ні-оп. Знищіть тестовий пул, коли закінчите.

Три міні-історії з корпоративного життя (реалістично правдоподібні)

1) Інцидент, спричинений неправильним припущенням: «SSD означає, що фрагментації не буває»

Усе почалося з тікета «бази даних повільні» з типовим тоном: розмиті графіки, гучні думки, відсутність кроків для відтворення. Пул зберігання був all-SSD RAIDZ, і команда мала стійке припущення, що затримки SSD такі малі, що деталі розміщення файлів — це дрібниці.

Але симптомом не була середня затримка; це були періодичні сплески. База працювала нормально, доки раптом не «посипалася», і тоді запити масово тайм-аутувалися. Графіки показували стрибки затримки запису, потім стабілізацію, потім знову стрибок — як сердечний ритм, тільки пацієнтом була система, що приносить дохід.

Ми виявили, що пул працює понад 85% і фрагментація зростає. До того ж autotrim ніколи не був увімкнений, а середовище мало сильний churn: короткочасні staging-датасети, часті створення/знищення снапшотів і CI-пайплайн, що ставив зберігання у розряд одноразового посуду.

Ось неправильне припущення: «ZFS знає вільний простір, отже SSD теж». Ні. Те, що ZFS знає про вільний простір, не означає автоматично, що SSD знає, які сторінки флеші можна негайно викинути з розгляду при зборі сміття. Тому диски робили більше внутрішнього копіювання, щоб підтримати записи, і ця робота проявлялася у хвостових сплесках затримки, коли контролер вирішував прибрати будинок.

Виправлення не було героїчним. Ми увімкнули autotrim, запланували початковий zpool trim у години з низьким трафіком і — що важливіше — перестали експлуатувати пул у стилі «ще можна створити один датасет». Через місяць «випадкові» стрибки майже зникли. Команда засвоїла урок, який тепер повторює новачкам: SSD не скасовує фізику; він просто переносить її у прошивку.

2) Оптимізація, яка обернулася проти нас: «Давайте обрізати все, завжди, прямо зараз»

Інший заклад, та сама проблема: деградація продуктивності за місяці. Доброзичливий інженер запропонував нічний ручний trim на кожному пулі, бо «на моєму ноуті працювало». Він додав це в cron, запустив опівночі і пішов додому відчувати себе відповідальним.

О 00:07 почав дзвонити on-call. Пакетні системи обробки — теж заплановані опівночі — наштовхнулися на стіну. Пул не був недоступним. Він був живим і болісно повільним. Затримки зросли, глибина черги зросла, а команда додатків почала підвищувати кількість повторних спроб, що є промисловим еквівалентом підливання бензину в багаття, щоб «він був теплішим».

Провал був простим: trim — це I/O. На тій конкретній моделі SATA SSD команди discard фактично серіалізувалися і конкурували з записами. Робота з trim перетворила контролер SSD у однополосний міст саме тоді, коли найжвавіший трафік хотів пройти.

Поступове рішення було більш витонченим. Ми прибрали нічний trim. Увімкнули autotrim для стабільного стану, а ручний trim залишили лише після відомих великих звільнень (наприклад, видалення великого вікна ретеншену) і лише у вікнах, де пакетні завдання не виконувалися. Ми також додали моніторинг, що корелює активність trim з затримками запису, щоб помічати «TRIM сьогодні шкодить» замість гадання.

Мораль оптимізації: Якщо ви плануєте «обслуговування» опівночі, бо це «тихі години», можливо, ви живете в 2009 році. У 2025 опівніч — це коли запускаються завдання, бекапи, компакції, і всі вдають, що інтернет спить. Він не спить.

3) Нудна, але правильно зроблена практика, що врятувала день: зміна з контролем + петлі валідації

Це не гламурно, саме тому варто розповісти. Команда керувала мультиорендним кластером віртуалізації на дзеркалах ZFS NVMe. Вони хотіли autotrim, бо churn VM був постійним, а передбачуваність продуктивності важила більше, ніж пікові IOPS.

Вони зробили нудну річ: впровадили це поетапно. Увімкнули autotrim на одному некритичному пулі спочатку, потім спостерігали zpool iostat, латентність на рівні пристрою та продуктивність, видиму гостями, протягом тижня. Також вони перевірили підтримку discard скрізь, протестувавши VM, яка відправляла discards (і підтвердивши, що ZFS бачить звільнення, а пул показує активність trim).

Потім вони розгортали по пулах з планом відкату: якщо хвостова латентність перевищить поріг, вони вимкнуть autotrim і запланують ручні trims у відомо тихі вікна. Вони задокументували це і повідомили командам додатків, чого очікувати.

Через два місяці бага в прошивці однієї лінії SSD викликала періодичні зупинки контролера під важкими командами управління наборами даних. Їхній моніторинг швидко це виявив, бо був базовий рівень метрик з фазного розгортання. Вони тимчасово вимкнули autotrim на уражених пулах, стабілізували продуктивність і оновили прошивку під час планового технічного вікна.

Ніяких героїчних вчинків. Ніяких звинувачень. Просто петля зворотного зв’язку і дисципліна, яка не отримує овацій, але дозволяє компанії працювати.

Вплив на продуктивність та налаштування

Autotrim зазвичай дає позитивний ефект на сучасних SSD, але «зазвичай» не є SLA. Вплив залежить від:

• Поведінки диска та прошивки: деякі пристрої трактують discard як дешеву метаданну операцію; інші виконують реальну роботу негайно.
• Транспорту: NVMe загалом краще справляється з чергуванням, ніж SATA; SAS може різнитися в залежності від expander/контролера.
• Навантаження: навантаження з високим churn і випадковими записами виграють найбільше; здебільшого читальні архівні датасети майже цього не помітять.
• Заповненість пулу: майже повні пули посилюють усе: конкуренцію за алокації, поведінку метаслабів та тиск GC на пристрої.
• Ретеншен снапшотів: снапшоти закріплюють блоки, зменшуючи те, що можна звільнити — а отже, і те, що можна обрізати.

Є також тонке питання: autotrim змінює час виконання роботи. Без нього SSD може відкладати очистку до критичного моменту, спричиняючи рідкісні, але жорстокі стрибки затримки. З autotrim ви можете побачити більш постійну фонову активність. Багато продакшн-команд віддають перевагу «помірному стабільному фоновому шуму» перед «неочікуваним обривом латентності».

Коли я вагався б перед увімкненням autotrim?

• Коли «SSD» знаходиться за віртуалізаційним шаром, який бреше про підтримку discard або реалізує її погано.
• На відомо проблемних SATA SSD у середовищах з інтенсивними записами без достатнього резерву продуктивності.
• Коли відсутна спостережуваність; ввімкнути його в сліпу — це як почати відладки на основі відчуттів.

Швидкий план діагностики

Це послідовність «повільно і всі дивляться на вас». Мета — швидко вирішити, чи вузьке місце: (a) поведінка алокацій на рівні ZFS/пула, (b) збір сміття/взаємодія trim на рівні пристрою, чи (c) щось інше зовсім.

Step 1: Confirm it’s storage latency, not CPU or network

• Перевірте метрики додатка: чи таймаути збігаються з очікуванням диска?
• Перевірте систему: CPU iowait, чергу виконання та мережеві ретрансляції.

cr0x@server:~$ uptime
 03:41:12 up 94 days,  5:22,  2 users,  load average: 1.12, 1.44, 1.51

cr0x@server:~$ vmstat 1 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  0      0 821244  55432 9123456    0    0   120   890 4120 8200 15  7 70  8  0

Інтерпретація: Зростання wa (iowait) одночасно зі скаргами — це підказка, а не вирок. На сучасних системах воно може вводити в оману, але це швидкий тест на запах проблеми.

Step 2: Check pool health and obvious throttles

cr0x@server:~$ sudo zpool status tank
  pool: tank
 state: ONLINE
status: Some supported features are not enabled on the pool.
action: Enable all features using 'zpool upgrade'. Once this is done, the pool may no longer be accessible by software that does not support the features.
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
            nvme0n1 ONLINE       0     0     0
            nvme1n1 ONLINE       0     0     0

errors: No known data errors

Інтерпретація: Якщо йде resilver або scrub, то цей фоновий I/O може домінувати. Якщо помилки зростають, «проблема продуктивності» іноді є системою, що безуспішно повторює операції.

Step 3: Look at real-time pool I/O vs device I/O

cr0x@server:~$ sudo zpool iostat -v tank 1

Інтерпретація: Якщо записів на пулі багато, але завантаження пристрою запекле з зростанням латентності — ви обмежені пристроєм. Якщо завантаження низьке, але латентність додатка висока — підозрюйте налаштування sync, лог-пристрої або контенцію вищого рівня.

Step 4: Check if trim/autotrim activity is coincident with pain

cr0x@server:~$ sudo zpool status -t tank

Інтерпретація: Якщо trim виконується й ваше навантаження страждає, зупиніть його (zpool trim -s) і подивіться, чи відновиться латентність. Це не постійне рішення, але це експеримент з високим сигналом.

Step 5: Validate discard support and path correctness

cr0x@server:~$ lsblk -D

Інтерпретація: Якщо discard не підтримується (або виглядає як нуль), autotrim не допоможе. Тоді ваші варіанти — поведінка прошивки диска, більше overprovisioning або зміна пристрою/контролера.

Step 6: Check pool fullness, fragmentation, and snapshot pinning

cr0x@server:~$ sudo zpool list -o name,cap,frag
NAME  CAP  FRAG
tank  87%  62%

cr0x@server:~$ sudo zfs list -t snapshot | wc -l
14328

Інтерпретація: Висока заповненість + висока фрагментація + багато снапшотів = повільні записи, що чекають на відбування. TRIM може допомогти SSD, але ваш більший ворог — це поведінка алокації під тиском.

Типові помилки: симптоми та виправлення

Mistake 1: Enabling autotrim and benchmarking immediately

Симптом: «Ми увімкнули autotrim і продуктивність стала гіршою.»

Чому так відбувається: Ви щойно додали фонову роботу та одночасно вимірюєте фронтову роботу. Ви тестуєте «систему під час обслуговування», а не «систему в стабільному стані».

Виправлення: Виміряйте до, увімкніть autotrim, потім вимірюйте після стабілізації. Якщо потрібне початкове очищення, заплануйте zpool trim в поза-піковий час і бенчмаркуйте після завершення.

Mistake 2: Assuming deletes in guests free space on the host

Симптом: Гість видаляє дані, але алокація пулу не падає; SSD з часом все одно сповільнюються.

Чому так відбувається: Discard має пройти шлях гостьова ФС → віртуальний диск → zvol → пул. Багато шарів за замовчуванням «не роблять discard».

Виправлення: Переконайтеся, що discard у гостя увімкнено та підтримується, і перевірте zfs list логічне vs фізичне використання та активність trim. Autotrim допомагає тільки після того, як ZFS помічає звільнення блоків.

Mistake 3: Running manual trims on a schedule without load awareness

Симптом: Передбачувані нічні сплески латентності або колапси пропускної здатності.

Чому так відбувається: Trim конкурує з реальним I/O і може серіалізуватися на деяких пристроях.

Виправлення: Віддавайте перевагу autotrim для стабільного стану; зберігайте ручний trim для подій після великих звільнень і запускайте з моніторингом та кнопкою зупинки.

Mistake 4: Treating TRIM as a cure for a nearly full pool

Симптом: Autotrim увімкнено, але записи все одно повільні, і попередження про простір не припиняються.

Чому так відбувається: При великій заповненості пулу алокація ZFS стає обмеженою й ефективний overprovisioning SSD зникає.

Виправлення: Зменшіть заповненість (видаліть, перемістіть, додайте vdev), відрегулюйте політику снапшотів і тримайте запас. Думайте «керування ємністю», а не «чарівна команда».

Mistake 5: Using the wrong ashift (and blaming trim)

Симптом: Постійний write amplification, погана продуктивність малих записів, високе навантаження записів на пристрій.

Чому так відбувається: Неправильне вирівнювання секторів примушує read-modify-write і додаткову внутрішню роботу на SSD.

Виправлення: Встановіть ashift=12 (або більше, коли доречно) при створенні пулів. Ви не можете змінити ashift на місці; це рішення щодо перебудови/міграції. Autotrim не врятує неправильно вирівняний пул.

Mistake 6: Trusting a RAID controller or expander that eats discard

Симптом: zpool set autotrim=on показує увімкнено, але lsblk -D вказує на відсутність discard, і продуктивність все одно деградує.

Чому так відбувається: Деякі проміжні пристрої не передають discard/UNMAP правильно.

Виправлення: Використовуйте HBA в IT-режимі для ZFS, тримайте прошивку в актуальному стані і валідуйте підтримку discard на рівні ОС.

Контрольні списки / покроковий план

Plan A: Enabling autotrim safely on an existing production pool

1. Базові метрики: зафіксуйте zpool iostat -v, iostat -x та затримки додатків за типовий період навантаження.
2. Перевірте підтримку discard: перевірте lsblk -D та підтвердіть, що пристрої дійсно SSD/NVMe у очікуваному шляху.
3. Перевірте запас пулу: впевніться, що заповненість не небезпечно висока й є план дій (зміни ретеншену, розширення).
4. Перевірте churn снапшотів: порахуйте снапшоти й визначте датасети, де видалення не звільнить простір через ретеншен.
5. Увімкніть autotrim: zpool set autotrim=on POOL.
6. Спостерігайте 24–72 години: стежте за хвостовими затримками та завантаженням пристроїв; шукайте кореляцію з активністю trim.
7. Вирішіть щодо початкового ручного trim: якщо пул має роки churn і ви ввімкнули autotrim пізно, запустіть zpool trim у контрольованому вікні.
8. Документуйте та автоматизуйте: додайте в ранбуки «як зупинити trim» і які метрики стежити.

Plan B: Ongoing operational hygiene (the boring stuff)

1. Тримайте пули поза зоною «завжди понад 80–85%», якщо вам не подобається рулетка продуктивності.
2. Щоквартально переглядайте політику ретеншену снапшотів; прив’язуйте її до бізнес-потреб, а не до звички.
3. Відстежуйте перцентилі затримок запису та завантаження пристроїв, а не лише пропускну здатність.
4. Підтримуйте прошивки та оновлення ОС на вузлах зберігання як пріоритетну задачу.
5. Тестуйте одне зміни за раз: autotrim, потім налаштування recordsize, потім sync/log зміни — ніколи не все одночасно.

Plan C: If you suspect autotrim is harming performance

1. Перевірте, чи виконується ручний trim: zpool status -t.
2. Зупиніть trim як експеримент: zpool trim -s.
3. Залиште autotrim увімкненим, але уникайте ручних trims; спостерігайте стабільність.
4. Якщо безперервний autotrim підозрюється у проблемі, встановіть autotrim=off і покладайтеся на періодичні ручні вікна.
5. Ескалація: перевірте прошивку, шлях контролера і розгляньте заміну пристрою, якщо обробка discard патологічна.

Питання та відповіді

1) Should I enable autotrim on all-SSD ZFS pools?

У більшості сучасних середовищ — так, особливо для пулів з інтенсивними записами або високим churn. Але робіть це з контролем видимості. Якщо ваші пристрої або контролери погано обробляють discard, autotrim може підвищити затримки під навантаженням.

2) What’s the difference between autotrim and zpool trim?

Autotrim — це безперервно: він відправляє trim при звільненнях з часом. zpool trim — це явний фоновий прохід, який обрізає вільні регіони пачками. Думайте «постійна гігієна» проти «глибокого прибирання».

3) Is this the same as fstrim?

Ні. fstrim працює на рівні файлової системи для традиційних блочних пристроїв. ZFS — це і volume manager, і файлова система; трим ZFS робиться ZFS. Запуск fstrim на ZFS-датасеті не працює так, як на ext4/xfs.

4) Will autotrim wear out my SSD faster?

Autotrim відправляє підказки discard; він не записує користувацькі дані. Це може спричинити, що SSD робитиме більше фонового стирання у різний час, але загальна мета — менше write amplification під час реальних записів. Знос більше визначається вашим навантаженням і overprovisioning, ніж наявністю TRIM-підказок.

5) I enabled autotrim but I don’t see anything happening. Is it broken?

Не обов’язково. Autotrim спрацьовує, коли ZFS звільняє блоки. Якщо снапшоти фіксують старі блоки або якщо ваше навантаження переважно додає дані з малим видаленням/перезаписом, може бути мало чого обрізати. Також перевірте підтримку discard через lsblk -D.

6) Can autotrim help with read performance?

Опосередковано — іноді. Головна користь — стабільна продуктивність запису і менша хвостова латентність шляхом зниження тиску GC. Читання можуть покращитись, якщо SSD менш зайнятий фоновими GC під час фронтових операцій.

7) Should I enable autotrim on mixed HDD/SSD pools?

Autotrim важливий для SSD-vdev. Для HDD це не має значення. Якщо у вас є спеціальні vdev або SLOG на SSD, розгляньте autotrim, щоб ці SSD-компоненти залишалися здоровими під метаданним/логовим churn. Перевірте підтримку пристрою і спостерігайте.

8) Does TRIM reclaim space inside ZFS?

Ні. ZFS вже відстежує простір. TRIM каже SSD, які LBA не використовуються, щоб SSD міг краще керувати флешем. Ваші zfs list і zpool list числа не змінюються через TRIM; вони змінюються через звільнення.

9) Why does performance still degrade even with autotrim enabled?

Поширені причини: пул занадто повний, ретеншен снапшотів фіксує блоки, вибір ashift/volblocksize спричинює write amplification, навантаження синхронне без відповідного SLOG або discard фактично не доходить до диска.

10) What’s the safest rollout strategy?

Увімкніть autotrim на одному пулі спочатку, спостерігайте принаймні тиждень, потім поступово розгортайте. Майте план відкату (вимкнути autotrim, зупинити ручні trims) і чіткий набір метрик (перцентилі затримок, завантаження пристроїв, глибина черги).

Висновок

ZFS autotrim — не магічний перемикач, але це одна з рідкісних опцій у продакшні, яка справді може допомогти SSD-пулам довше відчувати себе «новими» — особливо при інтенсивному churn. Фокус у тому, щоб ставитись до нього як до будь-якої іншої зміни, що впливає на таймінги I/O: підтвердьте підтримку discard по всьому шляху, розгорніть з метриками і не плутайте «фонове обслуговування» з «безкоштовним приростом продуктивності».

Якщо ви візьмете одну операційну настанову з цього матеріалу: оптимізуйте під передбачуваність. Autotrim часто міняє рідкісні катастрофічні сплески латентності на стабільну, керовану фонову роботу. У продакшні це вигідний обмін — бо передбачувані системи не будять вас посеред ночі, і вони точно не змушують команду бази даних запам’ятовувати ваш номер телефону.