TrueNAS ZFS recordsize: как выбрать размер записи для dataset

Что такое recordsize на практике

Recordsize задаёт максимальный размер логического блока для обычных файлов ZFS dataset. Это не означает, что каждый файл автоматически занимает ровно 128 KiB или 1 MiB: маленький файл и хвост большого файла могут использовать меньшие блоки. Параметр особенно важен при copy-on-write, сжатии и частичных перезаписях, потому что определяет гранулярность работы с данными. В интерфейсе TrueNAS Record Size находится в свойствах dataset; документация советует учитывать фиксированный размер данных, как у некоторых баз. Для zvol используется другой параметр — volblocksize, и переносить советы между dataset и zvol бездумно нельзя.

Важно: Не меняйте recordsize на zvol по инструкции для dataset: это разные свойства ZFS с разными последствиями.

Тип нагрузки и стартовый подход

• [object Object]
• [object Object]
• [object Object]
• [object Object]
• [object Object]
• [object Object]

Совет: Чем специализированнее workload, тем важнее документировать тест: размер файла, глубину очереди, sync/async, compression и cache. Иначе сравнение двух recordsize ничего не докажет.

Почему «самый большой» не всегда быстрее

Большой recordsize может быть выгоден для последовательного чтения мультимедиа: меньше метаданных и потенциально лучше эффективность сжатия. Но при частом изменении маленькой части большого логического блока система может читать и перезаписывать больше данных, чем нужно приложению. Маленький recordsize снижает гранулярность таких изменений, но увеличивает число блоков и метаданных, что тоже имеет цену. Поэтому оптимум определяется профилем I/O, а не объёмом самого файла. Большой виртуальный диск размером 500 ГБ может внутри получать тысячи мелких random writes, а маленький архив — читаться строго последовательно.

Как выбрать recordsize без гадания

1. Разделите разные нагрузки по отдельным datasets: медиатеку, backup, документы, базы и VM не стоит оптимизировать одной настройкой.
2. Зафиксируйте текущий recordsize и измерьте реальную работу: время копирования больших файлов, latency приложения, IOPS и CPU/ARC при типичном сценарии.
3. Проверьте рекомендации приложения. Если база явно оперирует страницами фиксированного размера, начните тест рядом с этим размером, а не с произвольного значения.
4. Измените recordsize только на тестовом dataset или перед записью новых данных. Старые блоки сами по себе не переписываются в новую геометрию.
5. Перезапишите репрезентативный набор данных и повторите тесты. Оставляйте изменение только при воспроизводимом выигрыше без ухудшения других важных метрик.

Предупреждение: Изменение свойства не «переформатирует» уже записанные файлы. Чтобы старые данные получили новую раскладку блоков, их нужно переписать.

Сжатие, ARC и recordsize

ZFS сжимает данные на уровне блоков, поэтому крупный логический блок может дать алгоритму больше материала для поиска повторяющихся паттернов внутри блока. Но физически хорошо сжимаемый блок занимает меньше места на диске, чем его логический размер, и это не значит, что каждый запрос читает из диска полный несжатый объём. ARC-кэш и prefetch также меняют картину: повторное чтение может обслуживаться из памяти и скрывать реальные свойства диска. Поэтому benchmark после очистки кэша и повседневное поведение сервера — разные задачи. Для домашнего NAS с медиатекой default часто достаточно хорош, и ручная оптимизация должна иметь измеримую цель.

Отдельно про dRAID и ограничения

В документации TrueNAS для dRAID отмечены минимальные размеры recordsize, связанные с фиксированной шириной stripe, а для последовательной нагрузки может быть полезен размер 1 MiB. Это не универсальная рекомендация для любого пула: она относится к dRAID и определённым паттернам I/O. Если ваш пул обычный mirror или RAIDZ, не переносите значение только потому, что оно встречается в примере dRAID. Сначала определите тип vdev и ограничение вашей версии TrueNAS. Конфигурации хранения меняются медленно, поэтому одна аккуратная проверка документации перед изменением дешевле многодневной миграции после неудачной настройки.

Почему тестировать нужно на отдельном dataset

Recordsize — свойство dataset, поэтому разделение нагрузок даёт безопасный способ эксперимента. Создайте тестовый dataset с тем же compression, quota и близкими ACL, запишите туда копию репрезентативных данных и измерьте именно те операции, которые тормозят в реальности. Не сравнивайте пустой cache одного теста с разогретым ARC другого. Для базы учитывайте fsync/sync write, для медиатеки — последовательное чтение через реальный SMB-клиент, для backup — скорость инкрементальных изменений. Если выигрыш меньше естественного разброса, дополнительная сложность настройки не оправдана.

Когда оставить значение по умолчанию

• Dataset хранит разные типы файлов и нет одного доминирующего паттерна I/O.
• Нет измеримой проблемы производительности, которую вы пытаетесь решить.
• Нагрузка упирается в сеть 1 GbE, а не в диски или latency ZFS.
• Вы не можете воспроизвести benchmark до и после изменения.
• Приложение не даёт рекомендаций по блочному размеру, а данные критичны для переноса.
• Изменение потребовало бы массово переписывать данные без понятной выгоды.

Что учитывать

Большой recordsize может быть выгоден для последовательного чтения мультимедиа: меньше метаданных и потенциально лучше эффективность сжатия. Но при частом изменении маленькой части большого логического блока система может читать и перезаписывать больше данных, чем нужно приложению. Маленький recordsize снижает гранулярность таких изменений, но увеличивает число блоков и метаданных, что тоже имеет цену. Поэтому оптимум определяется профилем I/O, а не объёмом самого файла. Большой виртуальный…

Источники и проверка

Фактическая часть сверена по первичным источникам (в т.ч. Datasets — Record Size). Пример и формулировки — редакция N1RO на 2026-09-21.

• Datasets — Record Size
• ZFS dRAID Primer