¿Existe alguna forma de crear copias de vacas en ZFS?

Question

Estoy intentando hacer copias de algunos archivos/directorios, pero de las diversas formas que conozco, todas parecen subóptimas.

Por ejemplo, btrfs puede, con el uso de cp --reflink=autogenerar rápidamente copias de archivos.

Lo que he probado:

1. Enlaces simbólicos: No es bueno. Archivo renombrado, enlace roto.
2. Hardlinks: Mejor, pero todavía no es bueno. Los cambios en un archivo cambiarán el otro y no necesariamente quiero que se cambie el otro archivo.
3. Cree una instantánea del conjunto de datos y luego clone la instantánea: esto puede funcionar, pero no bien. A menudo no busco una copia de todo el conjunto de datos, ni que las copias actúen como otro conjunto de datos. Luego están las relaciones padre/hijo entre el clon/instantánea/original, que según tengo entendido son difíciles, si no imposibles, de romper.
4. Utilizando zfs send/receivey habilitando la deduplicación, replique el conjunto de datos en un nuevo conjunto de datos: esto evita las relaciones padre/hijo del uso de un clon, pero aun así crea innecesariamente otro conjunto de datos y aún sufre la lentitud que implica que los archivos tengan que leerse al 100 % y los bloques referenciados nuevamente en lugar de escritos.
5. Copie archivos y deje que la deduplicación haga su trabajo: esto funciona, pero es lento porque los archivos deben leerse al 100% y luego volver a hacer referencia a los bloques en lugar de escribirlos.

La lentitud del envío/recepción de zfs y la copia física o sincronización se exacerba aún más porque la mayoría de las cosas se almacenan comprimidas y deben descomprimirse durante la lectura y luego comprimirse antes de que se active la deduplicación para hacer referencia a bloques duplicados.

En toda mi investigación, no he podido encontrar nada que se parezca remotamente a la simplicidad de --reflink en btrfs.

Entonces, ¿hay alguna forma de crear copias de vacas en ZFS? ¿O es copiar "físicamente" y dejar que dedup haga su trabajo la única opción real?

Answer 1

Creo que la opción 3, como la describió anteriormente, es probablemente su mejor opción. El mayor problema con lo que desea es que ZFS realmente solo maneja esta copia en escritura en el nivel de conjunto de datos/instantánea.

Recomiendo encarecidamente evitar el uso de dedup a menos que haya verificado que funciona bien con su entorno exacto. Tengo experiencia personal con la deduplicación que funciona muy bien hasta que se traslada un usuario más o un almacén de VM, y luego cae por un precipicio de rendimiento y causa muchos problemas. Sólo porque parece que está funcionando muy bien con sus primeros diez usuarios, su máquina podría fallar cuando agregue el undécimo (o el duodécimo, o el decimotercero, o lo que sea). Si desea seguir este camino, asegúrese absolutamente de tener un entorno de prueba que imite exactamente su entorno de producción y que funcione bien en ese entorno.

Volviendo a la opción 3, deberá configurar un conjunto de datos específico para contener cada uno de los árboles del sistema de archivos que desee administrar de esta manera. Una vez que lo haya configurado y completado inicialmente, tome sus instantáneas (una por conjunto de datos que diferirá ligeramente) y promuévalas luego en clones. Nunca vuelvas a tocar el conjunto de datos original.

Sí, esta solución tiene problemas. No digo que no, pero dadas las restricciones de ZFS, probablemente siga siendo el mejor. Encontré esta referencia a alguien que usa clones de manera efectiva:http://thegreyblog.blogspot.com/2009/05/sparing-disk-space-with-zfs-clones.html

No estoy muy familiarizado con btrfs, pero si admite las opciones que desea, ¿ha considerado configurar un servidor separado solo para admitir estos conjuntos de datos, usando Linux y btrfs en ese servidor?

Answer 2

La opción 5 es la mejor.

Con respecto a los conjuntos de datos padre/hijo en la opción 3, puede promover un clon y ya no será un hijo del conjunto de datos clonado. Todavía no consumirá bloques adicionales. Editar:Observó que esto sólo revierte la relación padre/hijo, no la destruye.

Con respecto a que las cosas se compriman/encripten y eso ralentice la copia, eso es completamente falso. Su procesador es mucho más rápido que su dispositivo de bloque (incluso si usa SSD). Solo para algunos números de ejemplo, digamos que se necesitan 10 segundos para leer un bloque, pero solo se necesita un segundo para descomprimirlo y 2 segundos para descifrarlo. El bloque 1 se lee en 10 segundos y se envía a la CPU. La CPU comienza a descomprimir y descifrar mientras el disco comienza a leer el bloque 2. La CPU finalizará su tarea en 3 segundos y luego pasará los siguientes 7 segundos esperando en el disco. Mientras tanto, el disco ha pasado exactamente la misma cantidad de tiempo leyendo esos dos bloques (20 segundos) independientemente de si los bloques están comprimidos o no.

Del mismo modo, durante la escritura, sólo se retrasa el primer bloque. La CPU comprime/cifra el bloque 1 y lo envía al disco. Mientras el disco escribe el bloque 1, la CPU comenzará a comprimir/cifrar los bloques siguientes. La CPU masticará bloques mucho más rápido de lo que el disco puede escribirlos, por lo que no es un problema. (Sí, es más complejo que esto, pero esto es lo esencial).

Perdón por la explicación demasiado larga de un punto menor de su pregunta, pero quería aclarar ese malentendido.