Есть ли способ создать копии коров в ZFS?

Question

Я пытаюсь сделать копии некоторых файлов/каталогов, но из нескольких известных мне способов все кажутся неоптимальными.

Например, btrfs может с помощью cp --reflink=autoбыстро генерировать коровьи копии файлов.

Что я пробовал:

1. Символические ссылки: Не работает. Переименованный файл, неработающая ссылка.
2. Hardlinks: Лучше, но все еще нехорошо. Изменения в одном файле изменят другой, а я не обязательно хочу, чтобы другой файл был изменен.
3. Создайте снимок набора данных, затем клонируйте снимок: это может работать, но не очень хорошо. Часто я не ищу копию всего набора данных или копии, которые будут вести себя как другой набор данных. Затем есть родительские/дочерние отношения между клоном/снимком/оригиналом, которые, как я понимаю, трудно, если не невозможно, разорвать.
4. Используя zfs send/receiveи включив дедупликацию, реплицируйте набор данных в новый набор данных: это позволяет избежать родительских/дочерних отношений, возникающих при использовании клона, но все равно без необходимости создает еще один набор данных и по-прежнему страдает от медленности, связанной с необходимостью 100%-ного чтения файлов и повторного обращения к блокам вместо их записи.
5. Копирование файлов и выполнение дедупликации: это работает, но медленно, поскольку файл(ы) необходимо прочитать на 100%, а затем повторно обратиться к блокам вместо записи.

Медлительность отправки/приема zfs, а также физического копирования или rsyncing еще больше усугубляется тем, что большинство данных хранится в сжатом виде и должно быть распаковано во время чтения, а затем сжато перед тем, как начнется дедупликация для ссылки на дублирующиеся блоки.

За все время моих исследований мне не удалось найти ничего даже отдаленно напоминающего простоту --reflink в btrfs.

Итак, есть ли способ создать cow-копии в ZFS? Или «физическое» копирование и предоставление дедупликации сделать свою работу — единственный реальный вариант?

Answer 1

Я думаю, что вариант 3, как вы описали выше, вероятно, ваш лучший выбор. Самая большая проблема с тем, что вы хотите, заключается в том, что ZFS на самом деле обрабатывает это копирование при записи только на уровне набора данных/снимка.

Я настоятельно рекомендую избегать использования дедупликации, если вы не убедились, что она хорошо работает с вашей конкретной средой. У меня есть личный опыт работы дедупликации, которая отлично работает до тех пор, пока не будет перемещен еще один пользователь или хранилище виртуальных машин, а затем производительность падает и возникает множество проблем. Просто потому, что кажется, что она отлично работает с вашими первыми десятью пользователями, ваша машина может упасть, когда вы добавите одиннадцатого (или двенадцатого, или тринадцатого, или кого-то еще). Если вы хотите пойти по этому пути, убедитесь, что у вас есть тестовая среда, которая в точности имитирует вашу производственную среду, и что она хорошо работает в этой среде.

Возвращаясь к варианту 3, вам нужно будет настроить определенный набор данных для хранения каждого из деревьев файловой системы, которыми вы хотите управлять таким образом. После того, как вы его настроите и первоначально заполните, сделайте снимки (по одному на набор данных, который будет немного отличаться) и продвиньте их в клоны. Никогда больше не трогайте исходный набор данных.

Да, у этого решения есть проблемы. Я не говорю, что их нет, но, учитывая ограничения ZFS, это все равно, вероятно, лучшее решение. Я нашел эту ссылку на человека, который эффективно использовал клоны:http://thegreyblog.blogspot.com/2009/05/sparing-disk-space-with-zfs-clones.html

Я не очень хорошо знаком с Btrfs, но если он поддерживает нужные вам параметры, рассматривали ли вы возможность создания отдельного сервера только для поддержки этих наборов данных, используя Linux и Btrfs на этом сервере?

Answer 2

Вариант 5 — лучший.

Что касается родительских/дочерних наборов данных в варианте 3, вы можете продвигать клон, и он больше не будет дочерним по отношению к клонированному набору данных. Он по-прежнему не будет использовать дополнительные блоки. Редактировать:Обратите внимание, что это только меняет отношения родитель/ребенок, а не разрушает их.

Что касается сжатия/шифрования данных и замедления копирования, то это полностью неверно. Ваш процессор намного быстрее, чем ваше блочное устройство (даже при использовании SSD). Просто для примера предположим, что чтение блока занимает 10 секунд, но его распаковка занимает всего одну секунду, а расшифровка — 2 секунды. Блок 1 считывается за 10 секунд и отправляется в ЦП. ЦП начинает распаковку и расшифровку, в то время как диск начинает считывать блок 2. ЦП завершит свою задачу за 3 секунды, а затем потратит следующие 7 секунд на ожидание на диске. Тем временем диск потратил точно такое же количество времени на чтение этих двух блоков (20 секунд) независимо от того, сжаты блоки или нет.

Аналогично при записи задерживается только первый блок. ЦП сжимает/шифрует блок 1 и отправляет его на диск. Пока диск записывает блок 1, ЦП начнет сжимать/шифровать последующие блоки. ЦП будет пережевывать блоки гораздо быстрее, чем диск сможет их записать, так что это не проблема. (Да, это сложнее, но суть такова.)

Извините за слишком длинное объяснение незначительного момента в вашем вопросе, но я хотел прояснить это заблуждение.