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

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

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

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

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

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

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

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

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

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

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

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

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

Вариант 5 самый лучший.

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

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

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

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