¿Hay alguna manera de crear copias de vaca en ZFS?

Estoy tratando de hacer copias vacías 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 vacías de archivos.

Lo que he intentado:

1. Enlaces simbólicos: No es bueno. Archivo renombrado, enlace roto.
2. Enlaces duros: mejor, pero aún 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, luego clone la instantánea: Esto puede funcionar, pero no bien. A menudo no busco una copia de todo el conjunto de datos, o 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. Con el uso zfs send/receivey la deducción habilitada, replicar el conjunto de datos en un nuevo conjunto de datos: esto evita las relaciones padre / hijo de usar un clon, pero aún crea innecesariamente otro conjunto de datos, y aún sufre de la lentitud involucrada en los archivos que deben leerse al 100% y los bloques referenciados nuevamente en lugar de escritos.
5. Copie los archivos y deje que Dedp haga su trabajo: esto funciona, pero es lento porque los archivos deben leerse al 100% y luego los bloques deben hacer referencia nuevamente en lugar de escribir.

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, luego comprimirse antes de que dedup se active para hacer referencia a bloques duplicados.

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

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

Creo que la opción 3 como has descrito anteriormente es probablemente tu 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.

Sugeriría encarecidamente evitar el uso de dedup a menos que haya verificado que funciona bien con su entorno exacto. Tengo experiencia personal con la deducción que funciona muy bien hasta que un usuario más o una tienda de VM se mudan, y luego se cae por un precipicio de rendimiento y causa muchos problemas. Solo porque parece que está funcionando muy bien con sus primeros diez usuarios, su máquina podría caerse cuando agrega el undécimo (o duodécimo, o decimotercero, o lo que sea). Si desea seguir esta ruta, asegúrese de tener un entorno de prueba que imite exactamente su entorno de producción y que funcione bien en ese entorno.

Regresando 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 desea administrar de esta manera. Una vez que lo haya configurado e inicialmente poblado, tome sus instantáneas (una por conjunto de datos que diferirá ligeramente) y promueva luego en clones. Nunca toque el conjunto de datos original nuevamente.

Sí, esta solución tiene problemas. No estoy diciendo que no, pero dadas las restricciones de ZFS, todavía es probablemente la 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 realmente familiarizado con btrfs, pero si admite las opciones que desea, ¿ha considerado configurar un servidor separado solo para admitir estos conjuntos de datos, utilizando Linux y btrfs en ese servidor?

La opción 5 es la mejor.

Con respecto a los conjuntos de datos padre / hijo en la opción 3, puede promocionar un clon y ya no será un hijo del conjunto de datos clonado. Todavía no usará bloques adicionales. Editar: señaló que esto solo invierte la relación padre / hijo, no la destruye.

Con respecto a las cosas que se comprimen / cifran y que ralentizan la copia, eso es completamente falso. Su procesador es mucho más rápido que su dispositivo de bloqueo (incluso si usa SSD). Solo para algunos números de ejemplo, digamos que toma 10 segundos leer un bloque, pero solo toma un segundo descomprimirlo y 2 segundos 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, mientras se escribe, solo 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 posteriores. 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 esta es la esencia).

Perdón por la explicación demasiado larga de un punto menor en su pregunta, pero quería aclarar esa idea errónea.