Чи є спосіб створити коров’ячі копії в ZFS?

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

Наприклад, btrfs може, з використанням cp --reflink=autoшвидко створювати коров’ячі копії файлів.

Що я спробував:

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

Повільність надсилання / прийому zfs та фізичного копіювання чи rsyncing ще більше посилюється, оскільки більшість речей зберігаються стислими та підлягають декомпресії під час читання, після чого стискаються, перш ніж дедуп починає посилатися на повторювані блоки.

У всіх своїх дослідженнях мені не вдалося знайти нічого віддаленого, що нагадувало б простоту --reflink у btrfs.

Отже, чи існує спосіб створення коров’ячих копій у ZFS? Або "фізично" копіювання та надання дедупу робити свою справу єдино реальним варіантом?

Я думаю, що варіант 3, як ви описали вище, - це, мабуть, найкраща ставка. Найбільшою проблемою з того, що ви хочете, є те, що ZFS дійсно обробляє це копіювання під час запису на рівні набору даних / знімка.

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

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

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

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

Варіант 5 - найкращий.

Що стосується наборів даних батьків / дітей у варіанті 3, ви можете просувати клон, і він більше не буде дочіркою клонованого набору даних. Він все ще не використовуватиме зайві блоки. Редагувати: Помічено, що це лише перевертає стосунки батька / дитини, а не руйнує їх.

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

Так само під час написання затримується лише перший блок. ЦП стискає / шифрує блок 1 і відправляє його на диск. Поки диск записує блок 1, процесор почне компресувати / шифрувати наступні блоки. Процесор буде пережовувати блоки набагато швидше, ніж диск може записати їх, так що це не проблема. (Так, це складніше, ніж це, але це суть.)

Вибачте за занадто довге пояснення другорядного моменту у вашому питанні, але я хотів прояснити це неправильне уявлення.