¿Cuál es el orden de los datos escritos en un sistema de archivos zfs en zfs en Linux?
El único documento específico que encontré enhttp://docs.oracle.com/cd/E36784_01/html/E36835/gkknx.htmldice;When a file is written, the data is compressed, encrypted, and the checksum is verified. Then, the data is deduplicated, if possible.
pero si eso fuera cierto, entonces la desduplicación no desduplicaría los bloques comprimidos con diferentes algoritmos de compresión.
Probé mysqlf y creo que el orden es el siguiente: dedup, compress, encrypt.
Mi configuración de prueba:
zpool create tank /dev/sdb
zfs create tank/lz4
zfs create tank/gzip9
zfs set compression=lz4 tank/lz4
zfs set compression=gzip-9 tank/gzip9
zfs set dedup=on tank
Salida dezfs list
NAME USED AVAIL REFER MOUNTPOINT
tank 106K 19,3G 19K /tank
tank/gzip9 19K 19,3G 19K /tank/gzip9
tank/lz4 19K 19,3G 19K /tank/lz4
generar un archivo aleatorio condd if=/dev/urandom of=random.txt count=128K bs=1024
131072+0 Datensätze ein
131072+0 Datensätze aus
134217728 Bytes (134 MB) kopiert, 12,8786 s, 10,4 MB/s
Salida de la lista zpool en un grupo vacío:
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
tank 19,9G 134K 19,9G - 0% 0% 1.00x ONLINE -
Luego copie los archivos a los conjuntos de datos con diferentes algoritmos de compresión:
cp random.txt /tank/lz4
cp random.txt /tank/gzip9
Salida zfs listdespués de copiar:
NAME USED AVAIL REFER MOUNTPOINT
tank 257M 19,1G 19K /tank
tank/gzip9 128M 19,1G 128M /tank/gzip9
tank/lz4 128M 19,1G 128M /tank/lz4
Salida de zpool listdespués de copiar:
NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT
tank 19,9G 129M 19,7G - 0% 0% 2.00x ONLINE -
La relación de deduplicación es2.0después de copiar el mismo archivo en diferentes conjuntos de datos. En mi opinión, esto significa que la deduplicación se realiza endatos-bloques antes de la compresión y el cifrado.
¿Alguien podría verificar si esto es correcto?
Respuesta1
Resulta quehttp://docs.oracle.com/cd/E36784_01/html/E36835/gkknx.htmles correcto.
Cuando se escribe un archivo, los datos se comprimen, se cifran y se verifica la suma de verificación. Luego, los datos se deduplican, si es posible.
Mi suposición con el archivo aleatorio fue incorrecta. Parece que ZFS cancela la compresión si no puede alcanzar una determinada relación de compresión mínima.
cita dehttps://wiki.illumos.org/display/illumos/LZ4+Compresión
Otra cosa particular a tener en cuenta es que el rendimiento de LZ4 con datos incompresibles es muy alto. Lo logra incorporando un mecanismo de "aborto temprano" que se activará si LZ4 no puede cumplir con la relación de compresión mínima esperada (12,5 % en ZFS).
Para realizar pruebas, creé un archivo de texto desde mi sistema de archivos con find / >> tree.txt.
Después de copiar el archivo a ambos conjuntos de datos y luego zpool get dedupratioregresar:
NAME PROPERTY VALUE SOURCE
tank dedupratio 1.00x -
Dedup es realmente la última parte de esta cadena de escritura. ¡Elegir diferentes algoritmos de compresión dará como resultado una dedupración deficiente!
Desafortunadamente mi versión ZoL no soporta el cifrado. Pero parece que cifrar diferentes conjuntos de datos también podría arruinar la deduplicación. Información sobre cifrado:https://docs.oracle.com/cd/E53394_01/html/E54801/gkkih.html