Esta primavera, ya hemos discutido algunos temas introductorios, como cómo verificar la velocidad de sus discos y qué es RAID . En el segundo de ellos, incluso prometimos continuar estudiando el rendimiento de varias topologías de discos múltiples en ZFS. Este es el sistema de archivos de próxima generación que se está implementando en todas partes: desde Apple hasta Ubuntu .

Bueno, hoy es el mejor día para conocer ZFS, lectores curiosos. Solo tenga en cuenta que, según una evaluación conservadora realizada por el desarrollador de OpenZFS, Matt Arens, "es realmente complicado".

Pero antes de llegar a los números, y lo harán, lo prometo, para todas las variantes de configuración de vosmidiskovoy ZFS, debe hablar sobre cómo hacer que ZFS almacene datos en el disco.

Zpool, vdev y dispositivo

Este diagrama de grupo completo incluye tres vdevs auxiliares, uno para cada clase y cuatro para RAIDz2.

Por lo general, no hay razón para crear un grupo de tipos y tamaños de vdev inapropiados, pero si lo desea, nada le impide hacerlo.

Comprender realmente el sistema de archivos ZFS , debe observar cuidadosamente su estructura real. Primero, ZFS combina los niveles tradicionales de gestión de volumen y el sistema de archivos. En segundo lugar, utiliza un mecanismo de copia transaccional al escribir. Estas características significan que el sistema es estructuralmente muy diferente de los sistemas de archivos ordinarios y las matrices RAID. El primer conjunto de componentes básicos para comprender: un grupo de almacenamiento (zpool), un dispositivo virtual (vdev) y un dispositivo real (dispositivo).

zpool

El grupo de almacenamiento de zpool es la estructura ZFS más alta. Cada grupo contiene uno o más dispositivos virtuales. A su vez, cada uno de ellos contiene uno o más dispositivos reales (dispositivo). Las piscinas virtuales son bloques autónomos. Una computadora física puede contener dos o más grupos separados, pero cada uno es completamente independiente de los demás. Los grupos no pueden compartir dispositivos virtuales.

La redundancia de ZFS está a nivel de dispositivos virtuales, pero no a nivel de agrupaciones. En el nivel de grupo, no hay absolutamente ninguna redundancia: si se pierde una unidad vdev o un vdev especial, se pierde todo el grupo junto con él.

Las agrupaciones de almacenamiento modernas pueden sobrevivir a la pérdida de un registro de caché o dispositivo virtual, aunque pueden perder una pequeña cantidad de datos sucios si pierden el registro vdev durante un corte de energía o un bloqueo del sistema.

Existe una idea errónea común de que las "bandas de datos" (tiras) de ZFS se registran en todo el grupo. Esto no es verdad. Zpool no es un RAID0 divertido en absoluto, es más bien un JBOD divertido con un complejo mecanismo de distribución variable.

En su mayor parte, los registros se distribuyen entre los dispositivos virtuales disponibles de acuerdo con el espacio disponible, por lo que, en teoría, todos se completarán al mismo tiempo. En versiones posteriores de ZFS, se tiene en cuenta el uso actual (utilización) de vdev: si un dispositivo virtual está significativamente más cargado que el otro (por ejemplo, debido a la carga de lectura), se omitirá temporalmente para la escritura, a pesar de la presencia del coeficiente de espacio libre más alto.

Un mecanismo de detección de reciclaje integrado en los métodos modernos de distribución de registros ZFS puede reducir la latencia y aumentar el rendimiento durante los períodos de carga inusualmente alta, pero esto no es carta blanca.mezcla involuntariamente HDD lentos y SSD rápidos en un grupo. Tal grupo desigual seguirá funcionando a la velocidad del dispositivo más lento, es decir, como si estuviera completamente compuesto por dichos dispositivos.

vdev

Cada grupo de almacenamiento consta de uno o más dispositivos virtuales (dispositivo virtual, vdev). A su vez, cada vdev incluye uno o más dispositivos reales. La mayoría de los dispositivos virtuales se utilizan para almacenar datos fácilmente, pero hay varias clases vdev auxiliares, que incluyen CACHE, LOG y SPECIAL. Cada uno de estos tipos de vdev puede tener una de cinco topologías: dispositivo único, RAIDz1, RAIDz2, RAIDz3 o espejo.

RAIDz1, RAIDz2 y RAIDz3 son variaciones especiales de lo que los antiguos llaman RAID doble paridad (diagonal). 1, 2 y 3 se refieren a cuántos bloques de paridad se asignan para cada banda de datos. En lugar de discos separados para paridad, los dispositivos RAIDz virtuales distribuyen uniformemente esta paridad entre los discos. Una matriz RAIDz puede perder tantos discos como bloques de paridad; si pierde a otro, fallará y se llevará el grupo de almacenamiento con él.

En los dispositivos virtuales reflejados (espejo vdev), cada bloque se almacena en cada dispositivo en vdev. Aunque son los espejos de dos anchos más comunes, puede haber cualquier número arbitrario de dispositivos en el espejo: en instalaciones grandes, los triples se usan a menudo para aumentar el rendimiento de lectura y la tolerancia a fallas. El espejo vdev puede sobrevivir a cualquier falla mientras al menos un dispositivo en vdev continúa funcionando.

Los vdevs individuales son inherentemente peligrosos. Tal dispositivo virtual no sobrevivirá a una sola falla, y si se usa como almacenamiento o un vdev especial, entonces su falla conducirá a la destrucción de todo el grupo. Ten mucho, mucho cuidado aquí.

Los dispositivos virtuales CACHE, LOG y SPECIAL se pueden crear utilizando cualquiera de las topologías enumeradas anteriormente, pero recuerde que perder un dispositivo virtual SPECIAL significa perder un grupo, por lo que se recomienda encarecidamente una topología redundante.

dispositivo

Este es probablemente el término más fácil de entender en ZFS: es literalmente un dispositivo de acceso aleatorio en bloque. Recuerde que los dispositivos virtuales están formados por dispositivos individuales, y el grupo está formado por dispositivos virtuales.

Los discos, magnéticos o de estado sólido, son los dispositivos de bloque más comunes que se utilizan como bloques de construcción vdev. Sin embargo, cualquier dispositivo con un identificador en / dev es adecuado, por lo que puede usar matrices RAID de hardware completas como dispositivos separados.

Un archivo sin formato simple es uno de los dispositivos de bloque alternativos más importantes desde los que se puede construir vdev. Probar grupos de archivos dispersos - Una forma muy conveniente de verificar los comandos del grupo y ver cuánto espacio hay disponible en el grupo o dispositivo virtual de esta topología.

Puede crear un grupo de prueba a partir de archivos dispersos en solo unos segundos, pero no olvide eliminar todo el grupo y sus componentes más tarde.

Suponga que desea colocar un servidor en ocho discos y planea usar discos de 10 TB (~ 9300 GiB), pero no está seguro de cuál La topología se adapta mejor a sus necesidades. En el ejemplo anterior, en cuestión de segundos construimos un grupo de prueba a partir de archivos dispersos, y ahora sabemos que RAIDz2 vdev de ocho unidades de 10 TB proporciona 50 TiB de capacidad útil.

Otra clase especial de dispositivos es SPARE (repuesto). Los dispositivos intercambiables en caliente, a diferencia de los dispositivos convencionales, pertenecen al grupo completo, no solo a un dispositivo virtual. Si falla algún vdev en el grupo y hay un dispositivo de repuesto conectado al grupo y accesible, entonces se unirá automáticamente al vdev afectado.

Después de conectarse al vdev afectado, el dispositivo de reserva comienza a recibir copias o la reconstrucción de los datos que deberían estar en el dispositivo perdido. En RAID tradicional, esto se llama reconstrucción, mientras que en ZFS se llama "recuperación".

Es importante tener en cuenta que los dispositivos de reemplazo no reemplazan permanentemente los dispositivos con fallas. Esto es solo un reemplazo temporal para reducir el tiempo durante el cual se observa la degradación de vdev. Después de que el administrador reemplazó el dispositivo vdev fallido, la redundancia se restaura a este dispositivo permanente y SPARE se desconecta de vdev y vuelve a funcionar como repuesto para todo el grupo.

Conjuntos de datos, bloques y sectores

El siguiente conjunto de componentes básicos que debe comprender en nuestro viaje a través de ZFS no es tanto el hardware, sino cómo se organizan y almacenan los datos. Omitimos varios niveles aquí, como el metaslab, para no acumular los detalles y mantener una comprensión de la estructura general.

Conjunto de datos

Cuando creamos un conjunto de datos por primera vez, muestra todo el espacio de grupo disponible. Luego establecemos la cuota y cambiamos el punto de montaje. ¡Magia!

Zvol es en su mayor parte un conjunto de datos, desprovisto de su capa de sistema de archivos, que reemplazamos aquí con un

sistema de archivos ext4 completamente normal . El conjunto de datos ZFS es más o menos lo mismo que un sistema de archivos montado estándar. Al igual que un sistema de archivos normal, a primera vista parece ser "simplemente otra carpeta". Pero también, como los sistemas de archivos montados convencionales, cada conjunto de datos ZFS tiene su propio conjunto de propiedades básicas.

En primer lugar, un conjunto de datos puede tener una cuota asignada. Si está instaladozfs set quota=100G poolname/datasetname, no puede escribir en la carpeta montada/poolname/datasetnamemás de 100 GiB.

¿Nota la presencia - y ausencia - de barras al comienzo de cada línea? Cada conjunto de datos tiene su propio lugar tanto en la jerarquía de ZFS como en la jerarquía de montaje del sistema. No hay una barra diagonal en la jerarquía de ZFS: comienza con el nombre del grupo y luego la ruta de un conjunto de datos al siguiente. Por ejemplo, pool/parent/childpara un conjunto de datos nombrado childbajo el conjunto parentde datos primario en un grupo con un nombre de creatividad pool.

Por defecto, el punto de montaje del conjunto de datos será equivalente a su nombre en la jerarquía ZFS, con una barra al principio - la piscina con el nombre se poolmonta como /pool, el conjunto de datos está parentmontado en /pool/parent, y el niño conjunto de datos se monta childen /pool/parent/child. Sin embargo, el punto de montaje del sistema para el conjunto de datos se puede cambiar.

Si indicamoszfs set mountpoint=/lol pool/parent/child, el conjunto de datos se pool/parent/childmonta en el sistema como /lol.

Además de los conjuntos de datos, debemos mencionar los volúmenes (zvols). Un volumen es aproximadamente similar a un conjunto de datos, excepto que en realidad no tiene un sistema de archivos, es solo un dispositivo de bloque. Puede, por ejemplo, crear zvolcon un nombre mypool/myzvol, luego formatearlo con el sistema de archivos ext4 y luego montar este sistema de archivos; ahora tiene el sistema de archivos ext4, ¡pero con soporte para todas las características de seguridad de ZFS! Esto puede parecer una tontería en una computadora, pero tiene mucho más sentido como backend cuando se exporta un dispositivo iSCSI.

Bloques

Un archivo está representado por uno o más bloques. Cada bloque se almacena en un dispositivo virtual. El tamaño del bloque suele ser igual al parámetro de tamaño de registro , pero se puede reducir a 2 ^ si hay metadatos o un archivo pequeño.

Realmente, no estamos bromeando sobre el gran daño al rendimiento si instala un cambio de ceniza demasiado pequeño.

En el grupo ZFS, todos los datos, incluidos los metadatos, se almacenan en bloques. El tamaño máximo de bloque para cada conjunto de datos se define en la propiedadrecordsize(tamaño de registro). El tamaño del registro puede variar, pero esto no cambiará el tamaño o la ubicación de los bloques que ya se han escrito en el conjunto de datos; es válido solo para los nuevos bloques a medida que se escriben.

A menos que se especifique lo contrario, el tamaño de grabación actual es de 128 KiB por defecto. Este es un tipo de compromiso difícil en el que el rendimiento no será ideal, pero no terrible en la mayoría de los casos. Recordsizese puede configurar en cualquier valor de 4K a 1M (con configuraciones adicionales recordsizepuede configurar aún más, pero rara vez es una buena idea).

Cualquier bloque se refiere a los datos de un solo archivo: no puede comprimir dos archivos diferentes en un bloque. Cada archivo consta de uno o más bloques, según el tamaño. Si el tamaño del archivo es menor que el tamaño del registro, se guardará en un bloque más pequeño; por ejemplo, un bloque con un archivo de 2 KiB ocupará solo un sector de 4 KiB en el disco.

Si el archivo es lo suficientemente grande y requiere varios bloques, todos los registros con este archivo tendrán un tamañorecordsize - incluido el último registro, cuya parte principal puede resultar ser espacio no utilizado .

Los volúmenes Zvol no tienen una propiedad recordsize ; en cambio, tienen una propiedad equivalente volblocksize.

Sectores

El último bloque de construcción más básico es el sector. Esta es la unidad física más pequeña que se puede escribir o leer desde la unidad base. Durante varias décadas, la mayoría de los discos utilizaron sectores de 512 bytes. Recientemente, la mayoría de las unidades están configuradas para 4 sectores KiB y, en algunos, especialmente SSD, 8 sectores KiB o incluso más.

ZFS tiene una propiedad que le permite establecer manualmente el tamaño del sector. Esta es una propiedad ashift. Es algo confuso que el cambio de ceniza sea una potencia de dos. Por ejemplo, ashift=9significa un tamaño de sector de 2 ^ 9 o 512 bytes.

ZFS solicita al sistema operativo información detallada sobre cada dispositivo de bloque cuando se agrega al nuevo vdev, y teóricamente establece automáticamente el cambio de ceniza de manera adecuada en función de esta información. Desafortunadamente, muchos discos mienten sobre el tamaño de su sector para mantener la compatibilidad con Windows XP (que no pudo entender los discos con otros tamaños de sector).

Esto significa que se recomienda encarecidamente al administrador de ZFS que conozca el tamaño real del sector de sus dispositivos e instale manualmenteashift. Si se establece un cambio de ceniza demasiado pequeño, entonces el número de operaciones de lectura / escritura aumenta astronómicamente. Por lo tanto, escribir "sectores" de 512 bytes en el sector real de 4 KiB significa escribir el primer "sector", luego leer el sector de 4 KiB, cambiarlo con el segundo "sector" de 512 bytes, escribirlo nuevamente en el nuevo sector de 4 KiB, y así sucesivamente para cada entrada

En el mundo real, tal penalización supera a las ashift=13SSD Samsung EVO, por lo que debe actuar , pero estas SSD mienten sobre el tamaño de su sector y, por lo tanto, se establece de forma predeterminada ashift=9. Si un administrador de sistema experimentado no cambia esta configuración, entonces esta SSD es más lenta que una HDD magnética normal.

A modo de comparación, para un tamaño demasiado grandeashiftprácticamente no hay penalidad. No hay una disminución real de la productividad, y el aumento del espacio no utilizado es infinitamente pequeño (o igual a cero con la compresión habilitada). Por lo tanto, recomendamos encarecidamente que incluso las unidades que realmente utilizan sectores de 512 bytes se instalen ashift=12o incluso ashift=13que miren con confianza hacia el futuro.

La propiedad se ashiftestablece para cada dispositivo virtual vdev, y no para el grupo , como muchos piensan erróneamente, y no cambia después de la instalación. Si accidentalmente derribó ashiftal agregar un nuevo vdev al grupo, entonces contaminó irrevocablemente este grupo con un dispositivo de bajo rendimiento y, por regla general, no hay otra forma que destruir el grupo y comenzar de nuevo. Incluso eliminar vdev no te salvará de una configuración rotaashift!

— ,

, , « » « »,

, — , ,

Copy on Write (CoW) es la base fundamental de lo que hace que ZFS sea tan increíble. El concepto básico es simple: si le pide al sistema de archivos tradicional que modifique el archivo, hará exactamente lo que solicitó. Si le pide al sistema de archivos que copie durante la grabación que haga lo mismo, dirá "bueno", pero le mentirá.

En cambio, el sistema de archivos de copia-escritura escribe la nueva versión del bloque modificado, y luego actualiza los metadatos del archivo para romper la conexión con el bloque anterior y asociar el nuevo bloque que acaba de escribir.

La desconexión de la unidad anterior y la conexión de la nueva se realiza en una sola operación, por lo que no se puede interrumpir: si restablece la alimentación después de que esto suceda, tiene una nueva versión del archivo, y si restablece la alimentación antes, entonces tiene la versión anterior. En cualquier caso, no habrá conflicto en el sistema de archivos.

La copia al escribir en ZFS se lleva a cabo no solo en el nivel del sistema de archivos, sino también en el nivel de administración del disco. Esto significa que ZFS no está sujeto a un espacio en el registro (un agujero en el RAID ), un fenómeno cuando la tira solo logró grabar parcialmente antes de que el sistema se bloqueara, con la matriz dañada después de un reinicio. Aquí la tira es atómica, vdev siempre es consistente y Bob es tu tío .

ZIL: Registro de intenciones de ZFS

ZFS — , ZIL,

, ZIL, .

SLOG, LOG-, — — , , — vdev, ZIL

ZIL — ZIL SLOG,

Hay dos categorías principales de operaciones de escritura: síncrono (sincronización) y asíncrono (asíncrono). Para la mayoría de las cargas de trabajo, la gran mayoría de las operaciones de escritura son asíncronas: el sistema de archivos le permite agregarlas y entregarlas en lotes, reduciendo la fragmentación y aumentando significativamente el rendimiento.

Las grabaciones sincrónicas son un asunto completamente diferente. Cuando una aplicación solicita una escritura síncrona, le dice al sistema de archivos: "Debe confirmar esto en la memoria no volátil en este momento , y hasta entonces no puedo hacer nada más". Por lo tanto, las grabaciones síncronas deben enviarse inmediatamente al disco, y si eso aumenta la fragmentación o reduce el ancho de banda, entonces que así sea.

ZFS trata los registros síncronos de manera diferente a los sistemas de archivos normales; en lugar de cargarlos inmediatamente en el almacenamiento normal, ZFS los registra en un área de almacenamiento especial llamada registro de intención ZFS: el registro de intención ZFS o ZIL. El truco es que estos registros también permanecen en la memoria, que se agregan junto con las solicitudes de escritura asincrónicas regulares, para luego ser volcados al almacenamiento como TXG perfectamente normales (Grupos de transacciones, Grupos de transacciones).

En funcionamiento normal, ZIL se graba y nunca se vuelve a leer. Cuando, después de unos momentos, las grabaciones de ZIL se arreglan en el almacenamiento principal en TXG ordinario de RAM, se desconectan de ZIL. Lo único cuando se lee algo de ZIL es al importar el grupo.

Si ZFS falla (el sistema operativo falla o se corta la corriente) cuando hay datos en ZIL, estos datos se leerán durante la próxima importación del grupo (por ejemplo, cuando se reinicia el sistema de emergencia). Todo lo que está en el ZIL se leerá, se combinará en grupos TXG, se comprometerá con el almacenamiento principal y luego se desconectará del ZIL durante el proceso de importación.

Una de las clases de ayuda vdev se llama LOG o SLOG, el dispositivo LOG secundario. Tiene una tarea: proporcionar al grupo un dispositivo vdev separado y, preferiblemente, mucho más rápido, con una resistencia de escritura muy alta para almacenar ZIL, en lugar de almacenar ZIL en el almacenamiento vdev principal. ZIL se comporta igual independientemente de la ubicación de almacenamiento, pero si vdev con LOG tiene un rendimiento de escritura muy alto, las escrituras sincrónicas serán más rápidas.

Agregar vdev con LOG al grupo no puede mejorar el rendimiento de escritura asíncrona, incluso si fuerza todas las escrituras a ZIL usando zfs set sync=always, todavía estarán vinculadas al repositorio principal en TXG de la misma manera y al mismo ritmo que sin un registro. La única mejora directa del rendimiento es el retraso en la grabación síncrona (ya que una mayor velocidad de registro acelera las operaciones sync).

Sin embargo, en un entorno que ya requiere una gran cantidad de escrituras sincrónicas, vdev LOG puede acelerar indirectamente las escrituras asincrónicas y las lecturas no almacenadas en caché. Cargar registros ZIL en un registro vdev separado significa menos competencia por IOPS en el almacenamiento primario, lo que en cierta medida mejora el rendimiento de todas las operaciones de lectura y escritura.

Instantáneas

El mecanismo de copia de escritura también es una base esencial para las instantáneas atómicas de ZFS y la replicación asíncrona incremental. El sistema de archivos activo tiene un árbol de punteros que marca todos los registros con datos actuales; cuando toma una instantánea, simplemente hace una copia de este árbol de punteros.

Cuando se sobrescribe un registro en el sistema de archivos activo, ZFS primero escribe la nueva versión del bloque en el espacio no utilizado. Luego, separa la versión anterior del bloque del sistema de archivos actual. Pero si alguna instantánea se refiere al bloque anterior, aún permanece sin cambios. ¡El viejo bloque no se restaurará en realidad como espacio libre hasta que se destruyan todas las instantáneas que enlazan con este bloque!

Replicación

Steam 2015 158 126 927 . rsync — ZFS « » 750% .

40- Windows 7 — . ZFS 289 , rsync — «» 161 , , rsync --inplace.

, rsync . 1,9 — , ZFS 1148 , rsync, rsync --inplace

Una vez que comprenda cómo funcionan las instantáneas, es fácil comprender la esencia de la replicación. Dado que una instantánea es solo un árbol de punteros a los registros, se deduce que si hacemos una zfs sendinstantánea, enviamos este árbol y todos los registros asociados con él. Cuando se pasa esta zfs senden zfs receiveque el objeto de destino, escribe tanto en el contenido real del bloque y el árbol de punteros que hacen referencia a los bloques para el conjunto de datos de destino.

Todo se vuelve aún más interesante en el segundo zfs send. Ahora tenemos dos sistemas, cada uno de los cuales contiene poolname/datasetname@1, y usted toma una nueva instantánea poolname/datasetname@2. Por lo tanto, en el grupo de origen que tiene datasetname@1y datasetname@2, y en el grupo de destino hasta ahora, solo la primera instantánea datasetname@1.

Dado que tenemos una instantánea común entre el origen y el destinodatasetname@1, podemos hacer incrementalmente zfs send encima. Cuando le decimos al sistema zfs send -i poolname/datasetname@1 poolname/datasetname@2, compara dos árboles de punteros. Los punteros que existen solo en @2, obviamente, se refieren a nuevos bloques, por lo que necesitamos el contenido de estos bloques.

En un sistema remoto, el procesamiento incremental es sendigual de simple. Primero, registramos todas las nuevas entradas incluidas en la secuencia sendy luego agregamos punteros a estos bloques. Voila, en nuestro @2nuevo sistema!

La replicación incremental asincrónica de ZFS es una gran mejora con respecto a los métodos anteriores que no son instantáneas como rsync. En ambos casos, solo se transmiten los datos modificados, pero rsync debe leer primerodesde el disco todos los datos en ambos lados para verificar la cantidad y compararla. Por el contrario, la replicación de ZFS no lee más que árboles de punteros y cualquier bloque que no esté representado en la instantánea general.

Compresión en línea

El mecanismo de copia en escritura también simplifica el sistema de compresión incorporado. En un sistema de archivos tradicional, la compresión es problemática: tanto la versión anterior como la nueva versión de los datos modificados están en el mismo espacio.

Si considera un dato en el medio de un archivo que comienza su vida como un megabyte de ceros desde 0x00000000 y así sucesivamente, es muy fácil comprimirlo en un sector del disco. Pero, ¿qué sucede si reemplazamos este megabyte de ceros con un megabyte de datos incompresibles como JPEG o ruido pseudoaleatorio? De repente, este megabyte de datos requerirá no uno, sino 256 sectores de 4 KiB, y en este lugar en el disco solo se reserva un sector.

ZFS no tiene ese problema, ya que los registros cambiados siempre se escriben en el espacio no utilizado: el bloque original ocupa solo un sector de 4 KiB, y un nuevo registro tomará 256, pero esto no es un problema: un fragmento recientemente cambiado desde el "medio" del archivo se escribiría en el espacio no utilizado independientemente de si su tamaño ha cambiado o no, por lo que para ZFS esta es una situación normal.

La compresión ZFS incorporada está deshabilitada de manera predeterminada, y el sistema ofrece algoritmos de complemento, ahora entre ellos están LZ4, gzip (1-9), LZJB y ZLE.

LZ4 es un algoritmo de transmisión que ofrece compresión y descompresión extremadamente rápidas y ganancias de rendimiento para la mayoría de los casos de uso, incluso en CPU bastante lentas.
GZIP — , Unix-. 1-9, CPU 9. ( ) , c CPU — , .
LZJB — ZFS. , LZ4 .
ZLE : codificación de nivel cero, codificación de nivel cero. No toca los datos normales en absoluto, pero comprime grandes secuencias de ceros. Útil para conjuntos de datos completamente incompresibles (por ejemplo, JPEG, MP4 u otros formatos ya comprimidos), ya que ignora los datos incompresibles, pero comprime el espacio no utilizado en los registros resultantes.

Recomendamos la compresión LZ4 para casi todos los casos de uso; La penalización de rendimiento por encontrar datos incompresibles es muy pequeña, y la ganancia de rendimiento para datos típicos es significativa. Copiar una imagen de máquina virtual para una nueva instalación del sistema operativo Windows (sistema operativo recién instalado, sin datos aún) compression=lz4pasado con un 27% más rápido que con compression=none, en esta prueba de 2015 .

ARC - caché de reemplazo adaptativo

ZFS es el único sistema de archivos moderno conocido por nosotros que utiliza su propio mecanismo de almacenamiento en caché de lectura y no se basa en la memoria caché de la página del sistema operativo para almacenar copias de los bloques leídos recientemente en la RAM.

Aunque su propio caché no está exento de problemas, ZFS no puede responder a las nuevas solicitudes de asignación de memoria tan rápido como el núcleo, por lo que una nueva llamada de malloc()asignación de memoria puede fallar si necesita RAM ocupada actualmente por ARC. Pero hay buenas razones para usar su propio caché, al menos por ahora.

Todos los sistemas operativos modernos conocidos, incluidos MacOS, Windows, Linux y BSD, utilizan el algoritmo LRU (menos utilizado recientemente) para implementar el caché de la página. Este es un algoritmo primitivo que eleva el bloque en caché "hacia arriba en la cola" después de cada lectura y empuja hacia arriba los bloques en "cola hacia abajo" según sea necesario para agregar nuevos errores de caché (bloques que deberían haberse leído desde el disco, no desde el caché) hacia arriba.

Por lo general, el algoritmo funciona bien, pero en sistemas con grandes conjuntos de datos de trabajo, LRU conduce fácilmente a la agitación, desplazando los bloques que se necesitan con frecuencia para dejar espacio para los bloques que nunca se volverán a leer del caché.

ARCO - un algoritmo mucho menos ingenuo, que puede considerarse como un caché "ponderado". Después de cada lectura del bloque en caché, se vuelve un poco "más pesado" y se hace más difícil desplazarse, e incluso después de desplazarse, el bloque se rastrea durante un cierto período de tiempo. Un bloque que se ha exprimido pero que debe volver a leerse en la caché también se volverá "más pesado".

El resultado final de todo esto es una memoria caché con una proporción de aciertos mucho mayor: la relación entre aciertos en la memoria caché (leída de la memoria caché) y errores (lectura desde el disco). Estas son estadísticas extremadamente importantes: no solo los golpes de caché en sí mismos sirven órdenes de magnitud más rápido, sino que los errores de caché también se pueden servir más rápido, porque cuantos más golpes de caché, menos solicitudes de disco concurrentes y menos demora para los errores restantes que deberían servirse conducir.

Conclusión

Después de estudiar la semántica básica de ZFS, cómo funciona la copia al escribir, así como las relaciones entre grupos de almacenamiento, dispositivos virtuales, bloques, sectores y archivos, estamos listos para discutir el rendimiento real con números reales.

En la siguiente parte, veremos el rendimiento real de los grupos con vdev reflejado y RAIDz, en comparación entre sí, así como en comparación con las topologías RAID de kernel de Linux tradicionales, que examinamos anteriormente .

Al principio, queríamos considerar solo lo básico, las topologías ZFS en sí mismas, pero después de esto , estaremos listos para hablar sobre ajustes y ajustes ZFS más avanzados, incluido el uso de tipos de vdev auxiliares como L2ARC, SLOG y Special Allocation.

Conceptos básicos de ZFS: almacenamiento y rendimiento