Я пытаюсь понять, почему существует большое несоответствие между используемым пространством производственного набора данных ZFS и набора данных резервного копирования, который заполняется с помощью ночной отправки zfs (я храню 30 ежедневных снимков и реплицирую каждую ночь - никакие другие системы не записывают или в противном случае получить доступ к резервному набору данных). Сжатие и дедупликация не включены ни с одной стороны. В наборе данных резервного копирования указано, что используется 315T, в то время как в производстве используется только 311T (две системы, по сути, являются зеркальными с точки зрения оборудования). Моя проблема в том, что ночные отправки zfs теперь не работают (не хватает места).
Последующий вопрос: есть ли очевидный выход из этой проблемы? Пул резервных копий показывает 10,7 ТБ свободно, но, похоже, это не доступно для набора данных, поскольку в нем указано только 567 ГБ. Если бы мне пришлось уничтожить пул резервных копий и выполнить полную zfs-отправку производственных данных, ожидать ли мы его завершения? Я уже уничтожил все, кроме двух последних снимков, в наборе данных резервной копии, но он не освободил достаточно места, чтобы разрешить новую отправку zfs. Я намеренно установил квоту в 312 ТБ для производственного набора данных, чтобы контролировать пользователей, поскольку они часто работают почти на 100%, но кажется, что квоты могло быть недостаточно? (для резервного пула / набора данных квота не определена)
Production system:
# zpool list
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
data 326T 311T 15.3T - 44% 95% 1.00x ONLINE -
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
data 311T 5.11T 96K /data
data/lab 311T 1.30T 306T /data/lab
Backup system:
# zpool list
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
backup 326T 315T 10.7T - 6% 96% 1.00x ONLINE -
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
backup 315T 567G 96K /backup
backup/lab 315T 567G 315T /backup/lab
На основе выход zdb в целевом (резервном) пуле нет устройства SLOG. Это означает, что выделяется дополнительный блок ЗИЛ. внутри бассейн обычное пространство, съедает в доступное пространство. В то время как устройство SLOG основного пула имеет "всего" ~ 185 ГБ (что слишком много для обычного SLOG), влияние на целевой пул может быть значительно больше, поскольку для работы ZIL постоянно выделяются новые блоки. Более того, это может привести к чрезмерной фрагментации метаслаб с большим объемом выделенного пространства.
РЕДАКТИРОВАТЬ: Другая возможная причина несоответствия размера может быть связана с самим zfs send / recv: по умолчанию он работает с максимальными параметрами совместимости, что может несколько раздуть принимающую сторону. Для получения дополнительной информации вы можете посмотреть сообщение рассылки Вот
НОТА: вышеприведенный ответ сделал явное предположение, что все остальное и были равно - например, если вы временно включили сжатие в исходном пуле, выделение пространства будет явно отличаться от целевого пула (если в нем никогда не было включено сжатие).
ИСПРАВИТЬ: Я не думаю, что добавление SLOG для пула резервных копий сейчас может быть полезным; скорее, я бы отрегулировал spa_slop_shift (увеличивая его), чтобы освободить значительное пространство. Значение по умолчанию - 5, попробуйте установить его на 6, выполнив echo 6 > /sys/module/zfs/parameters/spa_slop_shift. Последующий zfs list должен сообщать о значительно большем доступном пространстве (с нет изменить выделенное пространство, как показано zpool list).
Если вам нужно еще больше места, вы можете снова увеличить spa_slop_shift - но обязательно прочтите документацию, чтобы понять, что вы делаете.