Linus Torvalds incluirá dm-clone para la rama 5.4 del Kernel de Linux
Recientemente se dio a conocer la noticia que el creador del Kernel de Linux, “Linus Torvalds” aceptó en la rama del núcleo (sobre la base de la cual se forma la versión 5.4) la implementación del módulo dm-clone con la implementación de un nuevo controlador basado en Device-Mapper.
Esta nueva propuesta para el Kernel de Linux permitirá poder clonar un dispositivo de bloque existente. El módulo permite crear una copia local basada en un dispositivo de bloque de solo lectura que se puede grabar durante el proceso de clonación.
Como aplicación típica del modulo propuesto para el Kernel de Linux “dm-clone” se hace referencia a la clonación en red de dispositivos de archivo remotos en el modo de solo lectura y procesamiento de E/S con grandes retrasos, a un dispositivo local rápido que admite solicitudes de grabación y procesamiento con retrasos mínimos.
Con ello se brinda la capacidad de poder montar el dispositivo clonado y comenzar a usarlo inmediatamente después de su creación, sin esperar a que finalice el proceso de la transferencia de los datos.
Mientras que por otra parte la copia de información continuará en un segundo plano, en paralelo con la entrada/salida generada al acceder a un nuevo dispositivo.
El principal caso de uso de dm-clone es clonar una latencia potencialmente remota, dispositivo de bloqueo de tipo de archivo de solo lectura en un dispositivo de tipo primario grabable.
Por ejemplo dm-clone se puede usar para restaurar copias de seguridad del almacenamiento conectado a la red disponible a través de protocolos como NBD, Fibre Channel, iSCSI y AoE en el almacenamiento local basado en SSD o NVMe.
El código dm-clone está optimizado para pequeñas operaciones de escritura aleatoria cuyo tamaño coincide con el tamaño del bloque (4K por defecto).
Durante el proceso de clonación, las solicitudes de lectura conducirán a una solicitud directa de datos del dispositivo clonado y las solicitudes de escritura que afecten áreas que aún no se han sincronizado se retrasarán hasta que se complete la carga no programada de los bloques solicitados (las operaciones de carga para los bloques relacionados con la grabación se inician instantáneamente).
Los bloques eliminados mediante la operación “descartar” se excluyen del proceso de copia (después del montaje, el usuario puede ejecutar “fstrim/mnt/cloned-fs” para no copiar bloques que no se utilizan en el FS).
La información sobre los cambios y los datos en los bloques cargados se almacenan en una tabla de metadatos local separada.
Una vez completada la clonación, el usuario recibe una copia de trabajo completa del dispositivo fuente, que refleja todos los cambios realizados desde el inicio de la clonación.
Se puede eliminar una tabla con metadatos de clonación después de la sincronización reemplazándola por una tabla de líneas que refleje directamente los datos a un nuevo dispositivo.
La diferencia clave de las soluciones basadas en Unionfs y OverlayFS es que dm-clone funciona en el nivel de dispositivo de bloque, independientemente del sistema de archivos utilizado en este dispositivo, y forma una copia completa del dispositivo de origen y no impone una capa adicional en la que se rastrean los cambios.
A diferencia de dm-mirror, el módulo dm-clone se diseñó originalmente para funcionar solo con la sección original en modo de solo lectura, sin traducirle operaciones de escritura.
En dm-snapshot, no se crea una copia completa y no se admite la copia en segundo plano. En dm-cache, no se crea una copia completa, se reenvían las operaciones de escritura y el trabajo se reduce a aciertos de almacenamiento en caché. La funcionalidad más cercana es dm-thin.
dm-clone emplea dm-kcopyd para copiar partes del dispositivo fuente al dispositivo de destino. Por defecto, se emiten solicitudes de copia de un tamaño igual al tamaño de la región.
Se puede usar un mensaje `hydration_batch_size <#regions>` para ajustar el tamaño de estas solicitudes de copia. Aumentar el tamaño del lote de hidratación resulta en dm-clone tratando de agrupar regiones contiguas, por lo que copiamos los datos en lotes de estas muchas regiones.
Fuente: https://git.kernel.org