Хотя ответ пользователя user121391 в основном правильный, ограничение 1/4 для метаданных больше не имеет место / не было в течение длительного времени:
Существует ограничение на то, сколько кэша ZFS ARC может быть выделено для метаданных (и таблица дедупликации подпадает под эту категорию), и оно ограничено размером 1/4 ARC.
Прежде всего, zfs_arc_meta_limit (объем кэшируемой памяти, который может использоваться для метаданных, включая таблицу дедупликации) всегда был настраиваемым (iirc). Так что даже в очень старых версиях ZFS, где 25% могли быть значениями по умолчанию, вы можете использовать этот параметр для настройки объема кэша, доступного для метаданных.
В случае системы резервного копирования, где доступ к большинству пользовательских данных осуществляется редко, более подходящим может быть> = 75% для метаданных + <= 25% для пользовательских данных. Пожалуйста, имейте в виду, что указанная переменная - это доступный объем памяти в байтах, а не процент.
В зависимости от вашей реализации ZFS, пожалуйста, обратите внимание на следующее:
Для ZFS в Oracle Solaris 11 ограничение уже давно полностью удалено по умолчанию:
До внедрения этого изменения ARC ограничивала метаданные одной четвертью памяти. Каким бы ни было обоснование для этого, когда-то это могло иметь серьезное негативное влияние на производительность дедупликации. Поскольку ДДТ считается метаданными, на него распространяется ограничение 1/4. На данный момент этот предел является анахронизмом; это может быть устранено (или, скорее, установлено в arc_c).
Таким образом, хотя вы МОЖЕТЕ установить предел, он больше не рекомендуется.
Для ZFS в Linux до 0.6.x, например в Ubuntu 16.04, значение по умолчанию составляет 75%:
zfs_arc_meta_limit (ulong): максимально допустимый размер в байтах, который буфера метаданных разрешено использовать в ARC. Когда этот предел будет достигнут, буферы метаданных будут восстановлены, даже если общий arc_c_max не был достигнут. Это значение по умолчанию равно 0, что означает, что 3/4 ARC может использоваться для метаданных.
Также есть возможность настройки, если вы хотите убедиться, что минимальный объем памяти всегда зарезервирован для метаданных:
zfs_arc_meta_min (ulong): минимально допустимый размер в байтах, который буферы метаданных могут потреблять в ARC. Это значение по умолчанию равно 0, что отключает минимальное количество выделенных метаданных ARC.
В ZFS на Linux 0.7.0 кажется, что есть способ настроить объем памяти с процентным пределом:
zfs_arc_meta_limit_percent (ulong): процент ARC-буферов, которые можно использовать для метаданных. Смотрите также zfs_arc_meta_limit, который служит аналогичной цели, но имеет более высокий приоритет, если установлен в ненулевое значение.
Если вы планируете использовать реализацию ZFS на основе Linux, прежде чем тратить много $$$ на оборудование, подумайте о том, чтобы смоделировать ваш вариант использования на виртуальной машине. Я бы рекомендовал проверить наихудший случай дедупликации (= 100% случайных данных). Если у вас нет необходимых ресурсов виртуализации под рукой, имейте в виду, что вы всегда можете просто раскрутить безумно огромные экземпляры у большинства облачных провайдеров за пару часов за очень небольшие деньги.
И последнее, на что нужно обратить внимание: вы всегда можете настроить размер записей ZFS. Вообще говоря, небольшие размеры записи дают лучшие коэффициенты дедупликации (но, очевидно, требуют больше оперативной памяти для таблицы дедупликации). Большие размеры записи приведут к худшим коэффициентам дедупликации, но потребуют меньше оперативной памяти для таблицы дедупликации. Например: хотя в настоящее время мы не используем дедупликацию в нашем хранилище резервных копий ZFS, я установил размер записи ZFS равным 1M, чтобы соответствовать размеру блока, с которым работает наше приложение резервного копирования.
Не уверен, почему я только что написал докторскую диссертацию о кешировании метаданных ZFS, но надеюсь, что это поможет. :)
