Примусити контрольну суму оновлення zfs?

Нещодавно я змінив checksumвластивість однієї з моїх недублірованних файлових систем zfs на sha256з on(fletcher4), щоб краще підтримувати надсилання дублюваних пар реплікації, як у цій команді zfs send -DR -I _starting-snaphot_ _ending-snapshot_.

Однак, на сторінці zfs має бути сказане про send -D:

Цей прапор можна використовувати незалежно від властивості виведення набору даних, але продуктивність буде набагато кращою, якщо файлова система використовує контрольну суму, здатну до депонування (наприклад, sha256).

На сторінці zfs також зазначено про checksumвластивість:

Зміна цього властивості впливає лише на щойно написані дані.

У мене немає бажання довіряти fletcher4. Компроміс полягає в тому, що на відміну від SHA256, fletcher4 не є псевдовипадковою хеш-функцією, і тому не можна довіряти не стикатися. Таким чином, він підходить лише для дедупування у поєднанні з опцією 'verify', яка виявляє і вирішує хеш-колізії.

Як я можу оновити контрольні суми файлової системи, бажано, не виходячи за межі системи?

zfs zfsonlinux

— 84104
джерело

Для зміни властивостей (будь то компресона, дедуплікація чи контрольна сума) вже записаних даних, zfs підхід полягає у запуску даних через zfs send | zfs receiveпослідовність. Очевидно, що для цього вам не потрібно відключати систему, але це знадобиться

достатньо ресурсів у вашому zpool / у системі, щоб вмістити дві вичерпані копії відповідного набору даних
час простою для набору даних, оскільки вам або потрібно буде знищити їх або перейменувати в процедурі
достатньо часу та терпіння для завершення операції

Оскільки ви вже використовуєте дедупликацію для zpool, запуск zfs send | zfs receiveпункту призначення з тим самим пулом, як джерело, буде використовувати лише простір, необхідний для щойно написаних блоків метаданих. Але будьте готові до того, що копія займе певний час - дедупція може бути дуже повільною, особливо якщо у вас не вистачає оперативної пам'яті, щоб утримувати всю таблицю дедупінгу в оперативній пам'яті.

Вам, очевидно, потрібно буде припинити всі операції запису, щоб створити остаточну, авторитетну копію набору даних, але ви могли мінімізувати час простою, скопіювавши спочатку знімок, зупинивши всі записи та зробивши поступовий крок zfs send -i | zfs receiveяк останній крок.

— вабіт
джерело

Мені зовсім не зрозуміло, що zfs receiveоновлює метадані файлової системи. Мені здається, що це було б набагато швидше, якби просто взяли метадані такими, які є. Однак це може бути неможливим із-за рівня блоку контрольної суми, а не файлу. У такому випадку zfs send | zfs receiveформується прийнятна основа для рішення.

— 84104

zfs надіслати | zfs recv ефективно змінить усі метадані (вибір стиснення, вибір контрольної суми, вибір дедупування). zfs send - це створення об’єкта, який ви потім поглинаєте за допомогою zfs recv, який виписує його майже так, як ніби це все нові дані. Однак - я думаю, що ви можете зіткнутися з помилкою щодо zfs send | recv щодо дедуплікації. zfs надсилає -D спроби вивести дані / у самому потоці /, а не підтримувати існуючу дедупликацію даних із вихідного набору даних. Ось чому немає жодної вимоги, щоб сторона recv також увімкнула дедупцію на наборі даних.

— Nex7

Для подальшого пояснення - в даний час не існує можливості zfs надсилати | recv подвійні дані таким чином, що все, що йде по дроту, є єдиною копією здвоєних даних та пов'язаними з ними таблицями дедупірування. Навіть якщо джерело та місце призначення синхронізовані і ви надсилаєте не більше ніж поступовий знімок. ZFS все ще балонує відправлення даних у повному розмірі, якщо дані, що знаходяться в ньому, не піддаються видаленню / в межах самого потоку /. Можливо, у вас є дані, які легко виводяться в POOL DDT, але, як невеликий об'єкт відправки, бути повністю неприйнятним.

— Nex7