Suicide
23.09.2019, 22:48
Линус Торвальдс принял (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3e414b5bd28f965fb39b9e9419d877df0cf3111a) в ветку ядра, на основе которой формируется релиз 5.4, реализацию модуля dm-clone (https://www.redhat.com/archives/dm-devel/2019-September/msg00074.html) с реализацией нового обработчика на базе Device-Mapper, позволяющего (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/device-mapper/dm-clone.rst) клонировать существующее блочное устройство. Модуль даёт возможность на базе доступного в режиме только для чтения блочного устройства создать локальную копию, допускающую запись в процессе клонирования.
В качестве типового применения dm-clone упоминается клонирование по сети удалённых архивных устройств, доступных в режиме только для чтения и обрабатывающих ввод/вывод с большими задержками, в локальное быстрое устройство, поддерживающее запись и обрабатывающее запросы с минимальными задержками.
Клонированное устройство можно примонтировать и начать использование сразу после его создания, не дожидаясь завершения процесса переноса данных. Копирование информации будет продолжено в фоновом режиме, параллельно с вводом/выводом, образуемым при обращении к новому устройству. Например, dm-clone можно использовать для восстановления резервных копий из сетевых хранилищ, доступных по таким протоколам, как NBD, Fibre Channel, iSCSI и AoE, в локальное хранилище на базе SSD или NVMe. Код dm-clone оптимизирован для выполнения мелких операций случайной записи, размер которых соответствует размеру блока (по умолчанию 4K).
В процессе клонирования запросы на чтение будут приводить к прямому запросу данных с клонируемого устройства, а запросы на запись, затрагивающие ещё не синхронизированные области, будут откладываться до окончания внеплановой загрузки запрошенных блоков (операции загрузки для связанных с записью блоков инициируются мгновенно). Очищенные при помощи операции "discard" блоки исключаются из процесса копирования (после монтирования пользователь может выполнить "fstrim /mnt/cloned-fs" чтобы не копировать блоки, неиспользуемые в ФС).
Информация об изменениях и данные о загруженных блоках сохраняются в отдельной локальной таблице метаданных. После завершения клонирования пользователь получает полную рабочую копию исходного устройства, отражающую все изменения, выполненные с момента начала клонирования. Таблица с метаданными клонирования после синхронизации может быть удалена, путём замены на линейную таблицу, выполняющую прямое отражение данных на новое устройство.
Ключевым отличием от решений на базе Unionfs и OverlayFS является то, что dm-clone работает на уровне блочного устройства, независимо от применяемой на этом устройстве файловой системы, и формирует полную копию исходного устройства, а не накладывает дополнительный слой, в котором отслеживаются изменения. В отличие от dm-mirror модуль dm-clone изначально рассчитан на работу только с исходным разделом в режиме только для чтения, без трансляции в него операций записи. В dm-snapshot не создаётся полная копия и отсутствует поддержка фонового копирования. В dm-cache не создаётся полная копия, пробрасываются операции записи, а работа сводится к кэшированию обращений. Наиболее близким по функциональности является dm-thin, но он не поддерживает операции фонового копирования и ограничен только использованием определённых типов разделов (thin-provisioning).
23.09.2019
http://www.opennet.ru/opennews/art.shtml?num=51542
В качестве типового применения dm-clone упоминается клонирование по сети удалённых архивных устройств, доступных в режиме только для чтения и обрабатывающих ввод/вывод с большими задержками, в локальное быстрое устройство, поддерживающее запись и обрабатывающее запросы с минимальными задержками.
Клонированное устройство можно примонтировать и начать использование сразу после его создания, не дожидаясь завершения процесса переноса данных. Копирование информации будет продолжено в фоновом режиме, параллельно с вводом/выводом, образуемым при обращении к новому устройству. Например, dm-clone можно использовать для восстановления резервных копий из сетевых хранилищ, доступных по таким протоколам, как NBD, Fibre Channel, iSCSI и AoE, в локальное хранилище на базе SSD или NVMe. Код dm-clone оптимизирован для выполнения мелких операций случайной записи, размер которых соответствует размеру блока (по умолчанию 4K).
В процессе клонирования запросы на чтение будут приводить к прямому запросу данных с клонируемого устройства, а запросы на запись, затрагивающие ещё не синхронизированные области, будут откладываться до окончания внеплановой загрузки запрошенных блоков (операции загрузки для связанных с записью блоков инициируются мгновенно). Очищенные при помощи операции "discard" блоки исключаются из процесса копирования (после монтирования пользователь может выполнить "fstrim /mnt/cloned-fs" чтобы не копировать блоки, неиспользуемые в ФС).
Информация об изменениях и данные о загруженных блоках сохраняются в отдельной локальной таблице метаданных. После завершения клонирования пользователь получает полную рабочую копию исходного устройства, отражающую все изменения, выполненные с момента начала клонирования. Таблица с метаданными клонирования после синхронизации может быть удалена, путём замены на линейную таблицу, выполняющую прямое отражение данных на новое устройство.
Ключевым отличием от решений на базе Unionfs и OverlayFS является то, что dm-clone работает на уровне блочного устройства, независимо от применяемой на этом устройстве файловой системы, и формирует полную копию исходного устройства, а не накладывает дополнительный слой, в котором отслеживаются изменения. В отличие от dm-mirror модуль dm-clone изначально рассчитан на работу только с исходным разделом в режиме только для чтения, без трансляции в него операций записи. В dm-snapshot не создаётся полная копия и отсутствует поддержка фонового копирования. В dm-cache не создаётся полная копия, пробрасываются операции записи, а работа сводится к кэшированию обращений. Наиболее близким по функциональности является dm-thin, но он не поддерживает операции фонового копирования и ограничен только использованием определённых типов разделов (thin-provisioning).
23.09.2019
http://www.opennet.ru/opennews/art.shtml?num=51542