Esta primavera ya hemos discutido algunos temas introductorios, por ejemplo, и . En el segundo de ellos, incluso prometimos seguir estudiando el rendimiento de varias topologías multidisco en ZFS. Este es el sistema de archivos de próxima generación que ahora se está implementando en todas partes: desde a .
Bueno, hoy es el mejor día para familiarizarse con ZFS, lectores curiosos. Solo sepa que, en la humilde opinión del desarrollador de OpenZFS, Matt Ahrens, "es realmente difícil".
Pero antes de llegar a los números (y lo harán, lo prometo) para todas las opciones para una configuración ZFS de ocho discos, debemos hablar sobre cómo En general, ZFS almacena datos en disco.
Zpool, vdev y dispositivo
Este diagrama de grupo completo incluye tres vdevs auxiliares, uno de cada clase y cuatro para RAIDz2
Por lo general, no hay razón para crear un grupo de tipos y tamaños de vdev que no coincidan, pero no hay nada que le impida hacerlo si así lo desea.
Para comprender realmente el sistema de archivos ZFS, debe observar de cerca su estructura real. En primer lugar, ZFS unifica los niveles tradicionales de gestión de sistemas de archivos y volúmenes. En segundo lugar, utiliza un mecanismo de copia en escritura transaccional. Estas características significan que el sistema es estructuralmente muy diferente de los sistemas de archivos convencionales y las matrices RAID. El primer conjunto de bloques de construcción básicos para comprender son el grupo de almacenamiento (zpool), el dispositivo virtual (vdev) y el dispositivo real (dispositivo).
zpool
El grupo de almacenamiento zpool es la estructura ZFS superior. Cada grupo contiene uno o más dispositivos virtuales. A su vez, cada uno de ellos contiene uno o más dispositivos reales (dispositivo). Los pools 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á en el nivel del dispositivo virtual, no en el nivel del grupo. No hay absolutamente ninguna redundancia en el nivel del grupo: si se pierde una unidad vdev o un vdev especial, se perderá todo el grupo junto con él.
Los grupos de almacenamiento modernos pueden sobrevivir a la pérdida de un caché o un registro de dispositivo virtual, aunque pueden perder una pequeña cantidad de datos sucios si pierden el registro de vdev durante un corte de energía o un bloqueo del sistema.
Existe una idea errónea común de que las "franjas de datos" de ZFS se escriben en todo el grupo. Esto no es verdad. Zpool no es para nada divertido RAID0, es bastante divertido con un complejo mecanismo de distribución variable.
En su mayor parte, las entradas se distribuyen entre los dispositivos virtuales disponibles según el espacio libre disponible, por lo que en teoría se llenarán todos al mismo tiempo. En versiones posteriores de ZFS, se tiene en cuenta el uso (utilización) actual de vdev: si un dispositivo virtual está significativamente más ocupado que otro (por ejemplo, debido a la carga de lectura), se omitirá temporalmente para escritura, a pesar de tener la mayor cantidad libre. relación espacial.
El mecanismo de detección de utilización integrado en los métodos modernos de asignación de escritura de ZFS puede reducir la latencia y aumentar el rendimiento durante períodos de carga inusualmente alta, pero no es así. carta blanca en la mezcla involuntaria de HDD lentos y SSD rápidos en un grupo. Un grupo tan desigual seguirá funcionando a la velocidad del dispositivo más lento, es decir, como si estuviera completamente compuesto por tales dispositivos.
vdev
Cada grupo de almacenamiento consta de uno o más dispositivos virtuales (dispositivo virtual, vdev). A su vez, cada vdev contiene uno o más dispositivos reales. La mayoría de los dispositivos virtuales se utilizan para el almacenamiento de datos simples, pero existen varias clases auxiliares de vdev, incluidas CACHE, LOG y SPECIAL. Cada uno de estos tipos de vdev puede tener una de cinco topologías: dispositivo único (dispositivo único), RAIDz1, RAIDz2, RAIDz3 o espejo (espejo).
RAIDz1, RAIDz2 y RAIDz3 son variedades especiales de lo que los veteranos llamarían RAID de paridad doble (diagonal). 1, 2 y 3 se refieren a cuántos bloques de paridad se asignan para cada tira de datos. En lugar de discos separados para la paridad, los dispositivos virtuales RAIDz distribuyen esta paridad de manera semi uniforme entre los discos. Una matriz RAIDz puede perder tantos discos como bloques de paridad tenga; si pierde otro, se bloqueará y se llevará consigo el grupo de almacenamiento.
En los dispositivos virtuales espejados (mirror vdev), cada bloque se almacena en cada dispositivo en el vdev. Aunque los espejos de dos anchos son los más comunes, cualquier número arbitrario de dispositivos puede estar en un espejo; los triples se usan a menudo en grandes instalaciones para mejorar el rendimiento de lectura y la tolerancia a fallas. Un espejo vdev puede sobrevivir a cualquier falla siempre que al menos un dispositivo en el vdev continúe funcionando.
Los vdevs individuales son inherentemente peligrosos. Dicho dispositivo virtual no sobrevivirá a una sola falla, y si se usa como almacenamiento o como un vdev especial, su falla conducirá a la destrucción de todo el grupo. Ten mucho, mucho cuidado aquí.
CACHE, LOG y SPECIAL VA se pueden crear utilizando cualquiera de las topologías anteriores, pero recuerde que la pérdida de un SPECIAL VA significa la pérdida del 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 se componen de dispositivos individuales, mientras que un grupo se compone de dispositivos virtuales.
Los discos, ya sean magnéticos o de estado sólido, son los dispositivos de bloque más comunes que se utilizan como componentes básicos de vdev. Sin embargo, cualquier dispositivo con un descriptor en /dev funcionará, por lo que las matrices RAID de hardware completas se pueden usar como dispositivos separados.
Un archivo sin procesar simple es uno de los dispositivos de bloque alternativos más importantes a partir de los cuales se puede construir un vdev. Grupos de prueba de es una forma muy práctica de verificar los comandos del grupo y ver cuánto espacio hay disponible en un grupo o dispositivo virtual de una topología determinada.
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 después.
Supongamos que desea colocar un servidor en ocho discos y planea usar discos de 10 TB (~9300 GiB), pero no está seguro de qué topología se adapta mejor a sus necesidades. En el ejemplo anterior, creamos un grupo de prueba a partir de archivos dispersos en segundos, y ahora sabemos que un vdev RAIDz2 de ocho discos de 10 TB proporciona 50 TiB de capacidad utilizable.
Otra clase especial de dispositivos es SPARE (repuesto). Los dispositivos de intercambio en caliente, a diferencia de los dispositivos normales, pertenecen a todo el grupo y no a un solo dispositivo virtual. Si un vdev en el grupo falla y hay un dispositivo de repuesto conectado al grupo y disponible, se unirá automáticamente al vdev afectado.
Después de conectarse al vdev afectado, el dispositivo de repuesto comienza a recibir copias o reconstrucciones de los datos que deberían estar en el dispositivo faltante. En RAID tradicional, esto se denomina reconstrucción, mientras que en ZFS se denomina reconstrucción.
Es importante tener en cuenta que los dispositivos de repuesto no reemplazan permanentemente a los dispositivos defectuosos. Este es solo un reemplazo temporal para reducir la cantidad de tiempo que se degrada vdev. Una vez que el administrador reemplaza el vdev fallido, se restaura la redundancia en ese dispositivo permanente y el REPUESTO se desconecta del 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 debemos comprender en nuestro recorrido por ZFS se trata menos del hardware y más de cómo se organizan y almacenan los datos en sí. Nos estamos saltando algunos niveles aquí, como Metalab, para no saturar los detalles mientras mantenemos una comprensión de la estructura general.
Conjunto de datos (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 solo un conjunto de datos despojado de su capa de sistema de archivos, que estamos reemplazando aquí con un sistema de archivos ext4 perfectamente normal.
Un conjunto de datos ZFS es aproximadamente lo mismo que un sistema de archivos montado estándar. Al igual que un sistema de archivos normal, a primera vista parece "simplemente otra carpeta". Pero al igual que los sistemas de archivos montables regulares, 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á configurado zfs set quota=100G poolname/datasetname, entonces no podrá escribir en la carpeta montada /poolname/datasetname más de 100 GiB.
¿Observe 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 inclinada inicial 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/child para un conjunto de datos llamado child bajo el conjunto de datos principal parent en una piscina con un nombre creativo pool.
De forma predeterminada, el punto de montaje del conjunto de datos será equivalente a su nombre en la jerarquía de ZFS, con una barra inclinada inicial: el grupo denominado pool montado como /pool, conjunto de datos parent montado en /pool/parenty el conjunto de datos secundario child montado en /pool/parent/child. Sin embargo, el punto de montaje del sistema del conjunto de datos se puede cambiar.
si especificamos zfs set mountpoint=/lol pool/parent/child, entonces el conjunto de datos pool/parent/child montado en el sistema como /lol.
Además de los conjuntos de datos, debemos mencionar los volúmenes (zvols). Un volumen es más o menos lo mismo que un conjunto de datos, excepto que en realidad no tiene un sistema de archivos, es solo un dispositivo de bloque. Puede, por ejemplo, crear zvol Con nombre mypool/myzvol, luego formatéelo con un sistema de archivos ext4 y luego monte ese sistema de archivos: ¡ahora tiene un sistema de archivos ext4, pero con todas las funciones de seguridad de ZFS! Esto puede parecer una tontería en una sola máquina, pero tiene mucho más sentido como backend al exportar un dispositivo iSCSI.
Bloques
El 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 tamaño de registro, pero se puede reducir a 2^cambiosi contiene metadatos o un archivo pequeño.
Nosotros realmente realmente no bromeo sobre la gran penalización de rendimiento si establece un cambio demasiado pequeño
En un 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 propiedad recordsize (tamaño de registro). El tamaño del registro se puede cambiar, pero esto no cambiará el tamaño o la ubicación de ningún bloque que ya se haya escrito en el conjunto de datos; solo afecta a los bloques nuevos a medida que se escriben.
A menos que se especifique lo contrario, el tamaño de registro predeterminado actual es de 128 KiB. Es una especie de compensación complicada en la que el rendimiento no es perfecto, pero tampoco es terrible en la mayoría de los casos. Recordsize se puede configurar en cualquier valor de 4K a 1M (con configuraciones avanzadas recordsize puede instalar aún más, pero esto rara vez es una buena idea).
Cualquier bloque se refiere a los datos de un solo archivo; no puede meter dos archivos diferentes en un bloque. Cada archivo consta de uno o más bloques, dependiendo del tamaño. Si el tamaño del archivo es más pequeño que el tamaño del registro, se almacenará en un tamaño de 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ño recordsize - incluyendo la última entrada, la parte principal de la cual puede ser .
zvols no tiene una propiedad recordsize - en cambio, tienen una propiedad equivalente volblocksize.
Sectores
El último bloque de construcción, el más básico, es el sector. Es la unidad física más pequeña que se puede escribir o leer desde el dispositivo subyacente. Durante varias décadas, la mayoría de los discos utilizaron sectores de 512 bytes. Recientemente, la mayoría de los discos están configurados para sectores de 4 KiB y algunos, especialmente los SSD, tienen sectores de 8 KiB o incluso más.
El sistema ZFS tiene una propiedad que le permite establecer manualmente el tamaño del sector. Esta propiedad ashift. Algo confuso, un cambio es una potencia de dos. Por ejemplo, ashift=9 significa un tamaño de sector de 2^9, o 512 bytes.
ZFS consulta al sistema operativo para obtener información detallada sobre cada dispositivo de bloque cuando se agrega a un nuevo vdev y, en teoría, instala automáticamente un turno correctamente en función de esa información. Desafortunadamente, muchas unidades mienten sobre el tamaño de su sector para mantener la compatibilidad con Windows XP (que no pudo comprender las unidades con otros tamaños de sector).
Esto significa que se recomienda encarecidamente a un administrador de ZFS que conozca el tamaño real del sector de sus dispositivos y lo configure manualmente. ashift. Si se establece un desplazamiento demasiado bajo, el número de operaciones de lectura/escritura aumenta astronómicamente. Entonces, escribir "sectores" de 512 bytes en un sector real de 4 KiB significa tener que escribir el primer "sector", luego leer el sector de 4 KiB, modificarlo con un segundo "sector" de 512 bytes, escribirlo de nuevo en el nuevo Sector de 4 KiB, etc., para cada entrada.
En el mundo real, tal penalización afecta a los SSD EVO de Samsung, por lo que ashift=13, pero estos SSD mienten sobre el tamaño de su sector y, por lo tanto, el valor predeterminado se establece en ashift=9. Si un administrador de sistemas experimentado no cambia esta configuración, entonces este SSD funciona mas lento Disco duro magnético convencional.
A modo de comparación, para un tamaño demasiado grande ashift prácticamente no hay penalización. No existe una penalización de rendimiento real y el aumento en el espacio no utilizado es infinitesimal (o cero con la compresión habilitada). Por lo tanto, recomendamos enfáticamente que incluso aquellas unidades que usan sectores de 512 bytes instalen ashift=12 o ashift=13para afrontar el futuro con confianza.
propiedad ashift se establece para cada dispositivo virtual vdev, y no para la piscina, como muchos piensan erróneamente, y no cambia después de la instalación. Si accidentalmente golpeas ashift cuando agrega un nuevo vdev a un grupo, ha contaminado irremediablemente ese grupo con un dispositivo de bajo rendimiento y, por lo general, no hay otra opción que destruir el grupo y comenzar de nuevo. Incluso eliminar vdev no lo salvará de una configuración rota ashift!
Mecanismo de copia en escritura
Si un sistema de archivos regular necesita sobrescribir datos, cambia cada bloque donde está
Un sistema de archivos de copia en escritura escribe una nueva versión de bloque y luego desbloquea la versión anterior
En abstracto, si ignoramos la ubicación física real de los bloques, nuestro "cometa de datos" se simplifica a un "gusano de datos" que se mueve de izquierda a derecha en el mapa del espacio disponible.
Ahora podemos tener una buena idea de cómo funcionan las instantáneas de copia en escritura: cada bloque puede pertenecer a varias instantáneas y persistirá hasta que se destruyan todas las instantáneas asociadas.
El mecanismo Copy on Write (CoW) es la base fundamental de lo que hace de ZFS un sistema tan sorprendente. El concepto básico es simple: si le pide a un sistema de archivos tradicional que cambie un archivo, hará exactamente lo que le pidió. Si le pide a un sistema de archivos de copia en escritura que haga lo mismo, dirá "bien", pero le mentirá.
En cambio, un sistema de archivos de copia en escritura escribe una nueva versión del bloque modificado y luego actualiza los metadatos del archivo para desvincular el bloque anterior y asociar el bloque nuevo que acaba de escribir.
Separar el bloque anterior y vincular el nuevo se realiza en una sola operación, por lo que no se puede interrumpir: si apaga después de que esto suceda, tiene una nueva versión del archivo, y si apaga antes, tiene la versión anterior. . En cualquier caso, no habrá conflictos en el sistema de archivos.
La copia en escritura en ZFS se produce 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 se ve afectado por espacios en blanco () - un fenómeno cuando la tira tuvo tiempo de grabar solo parcialmente antes de que el sistema colapsara, con daños en la matriz después de un reinicio. Aquí la franja se escribe atómicamente, vdev siempre es secuencial y .
ZIL: registro de intenciones de ZFS
El sistema ZFS trata las escrituras síncronas de una manera especial: las almacena de forma temporal pero inmediata en ZIL antes de escribirlas de forma permanente más adelante junto con las escrituras asíncronas.
Por lo general, los datos escritos en un ZIL nunca se vuelven a leer. Pero es posible después de un bloqueo del sistema
SLOG, o dispositivo LOG secundario, es solo un vdev especial, y preferiblemente muy rápido, donde el ZIL se puede almacenar por separado del almacenamiento principal.
Después de un bloqueo, se reproducen todos los datos sucios en ZIL; en este caso, ZIL está en SLOG, por lo que se reproduce desde allí
Hay dos categorías principales de operaciones de escritura: síncronas (sync) y asíncronas (async). Para la mayoría de las cargas de trabajo, la gran mayoría de las escrituras son asincrónicas: el sistema de archivos permite agregarlas y emitirlas en lotes, lo que reduce la fragmentación y aumenta considerablemente el rendimiento.
Las grabaciones sincronizadas 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 ahora mismohasta entonces, no hay nada más que pueda hacer". Por lo tanto, las escrituras sincrónicas deben confirmarse en el disco de inmediato, y si eso aumenta la fragmentación o reduce el rendimiento, que así sea.
ZFS maneja las escrituras síncronas de manera diferente a los sistemas de archivos normales: en lugar de enviarlas inmediatamente al almacenamiento normal, ZFS las envía a un área de almacenamiento especial llamada ZFS Intent Log o ZIL. El truco es que estos registros también permanecen en la memoria, se agregan junto con las solicitudes de escritura asincrónicas normales y luego se descargan en el almacenamiento como TXG (grupos de transacciones) perfectamente normales.
En funcionamiento normal, el ZIL se escribe y nunca se vuelve a leer. Cuando, después de unos momentos, los registros de ZIL se asignan al almacenamiento principal en TXG ordinarios de RAM, se separan de ZIL. La única vez que se lee algo del ZIL es cuando se importa el grupo.
Si ZFS falla (un bloqueo del sistema operativo o un corte de energía) mientras hay datos en el ZIL, esos datos se leerán durante la próxima importación del grupo (por ejemplo, cuando se reinicie el sistema de emergencia). Cualquier cosa en el ZIL se leerá, se agrupará en TXG, se confirmará en el almacenamiento principal y luego se separará del ZIL durante el proceso de importación.
Una de las clases auxiliares de vdev se llama LOG o SLOG, el dispositivo secundario de LOG. Tiene un propósito: proporcionar al grupo un vdev separado, y preferiblemente mucho más rápido, muy resistente a la escritura para almacenar el ZIL, en lugar de almacenar el ZIL en la tienda vdev principal. El propio ZIL se comporta igual sin importar dónde esté almacenado, pero si LOG vdev tiene un rendimiento de escritura muy alto, las escrituras sincrónicas serán más rápidas.
Agregar un vdev con LOG al grupo no funciona no puedo mejorar el rendimiento de escritura asincrónica, incluso si fuerza todas las escrituras en ZIL con zfs set sync=always, seguirán vinculados al almacenamiento principal en TXG de la misma manera y al mismo ritmo que sin el registro. La única mejora directa del rendimiento es la latencia de las escrituras sincrónicas (porque un registro más rápido acelera las operaciones). sync).
Sin embargo, en un entorno que ya requiere muchas escrituras síncronas, vdev LOG puede acelerar indirectamente las escrituras asíncronas y las lecturas no almacenadas en caché. La descarga de entradas de ZIL en un LOG de vdev separado significa menos contención para IOPS en el almacenamiento principal, lo que mejora el rendimiento de todas las lecturas y escrituras hasta cierto punto.
Instantáneas
El mecanismo de copia en escritura también es una base necesaria 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 bloque anterior no se restaurará como espacio libre hasta que se destruyan todas las instantáneas que hacen referencia a este bloque!
Replicación
Mi biblioteca de Steam en 2015 era de 158 GiB e incluía 126 927 archivos. Esto está bastante cerca de la situación óptima para rsync: la replicación de ZFS a través de la red fue "solo" un 750 % más rápida.
En la misma red, replicar un solo archivo de imagen de máquina virtual de Windows 40 de 7 GB es una historia completamente diferente. La replicación de ZFS es 289 veces más rápida que rsync, o "solo" 161 veces más rápida si es lo suficientemente inteligente como para llamar a rsync con --inplace.
Cuando se escala una imagen de máquina virtual, los problemas de rsync se escalan con ella. 1,9 TiB no es tan grande para una imagen de máquina virtual moderna, pero es lo suficientemente grande como para que la replicación de ZFS sea 1148 veces más rápida que rsync, incluso con el argumento --inplace de rsync
Una vez que comprenda cómo funcionan las instantáneas, debería ser fácil comprender la esencia de la replicación. Dado que una instantánea es solo un árbol de punteros a registros, se deduce que si hacemos zfs send instantánea, luego enviamos este árbol y todos los registros asociados con él. Cuando enviamos esto zfs send в zfs receive en el destino, escribe tanto el contenido real del bloque como el árbol de punteros que hacen referencia a los bloques del conjunto de datos de destino.
Las cosas se ponen aún más interesantes en el segundo. zfs send. Ahora tenemos dos sistemas, cada uno conteniendo poolname/datasetname@1, y tomas una nueva instantánea poolname/datasetname@2. Por lo tanto, en el grupo original tienes datasetname@1 и 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 destino datasetname@1, podemos hacerlo incremental zfs send encima de eso. Cuando le decimos al sistema zfs send -i poolname/datasetname@1 poolname/datasetname@2, compara dos árboles de punteros. Cualquier puntero que solo exista en @2, obviamente se refieren a nuevos bloques, por lo que necesitamos el contenido de estos bloques.
En un sistema remoto, procesar un incremento send igual de sencillo. Primero escribimos todas las entradas nuevas incluidas en la transmisión. sendy luego agregue punteros a esos bloques. Voila, tenemos @2 en el nuevo sistema!
La replicación incremental asíncrona de ZFS es una gran mejora con respecto a los métodos anteriores que no se basaban en instantáneas, como rsync. En ambos casos, solo se transfieren los datos modificados, pero rsync debe hacerlo primero. leer del disco todos los datos de ambos lados para comprobar la suma y compararla. Por el contrario, la replicación de ZFS solo lee árboles de punteros y cualquier bloque que no esté presente en la instantánea compartida.
Compresión incorporada
El mecanismo de copia en escritura también simplifica el sistema de compresión en línea. 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 residen en el mismo espacio.
Si consideramos un dato en medio de un archivo que comienza como un megabyte de ceros desde 0x00000000 y así sucesivamente, es muy fácil comprimirlo en un sector en el disco. Pero, ¿qué sucede si reemplazamos ese megabyte de ceros con un megabyte de datos incompresibles como JPEG o ruido pseudoaleatorio? Inesperadamente, este megabyte de datos requerirá no uno, sino 256 sectores de 4 KiB, y en este lugar del disco solo se reserva un sector.
ZFS no tiene este problema, ya que los registros modificados siempre se escriben en el espacio no utilizado: el bloque original solo ocupa un sector de 4 KiB y el nuevo registro ocupará 256, pero esto no es un problema: un fragmento modificado recientemente del " 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 bastante normal.
La compresión nativa de ZFS está deshabilitada de forma predeterminada y el sistema ofrece algoritmos conectables, actualmente LZ4, gzip (1-9), LZJB y ZLE.
- LZ4 es un algoritmo de transmisión que ofrece una compresión y descompresión extremadamente rápida y beneficios de rendimiento para la mayoría de los casos de uso, incluso en CPU bastante lentas.
- GZIP es un algoritmo venerable que todos los usuarios de Unix conocen y aman. Se puede implementar con niveles de compresión del 1 al 9, con una relación de compresión y un aumento del uso de la CPU a medida que se acerca al nivel 9. El algoritmo es adecuado para todos los casos de uso de texto (u otros altamente comprimibles), pero por lo demás a menudo causa problemas de CPU: utilícelo con cuidado, especialmente en los niveles más altos.
- LZJB es el algoritmo original en ZFS. Está en desuso y no debería usarse más, el LZ4 lo supera en todos los sentidos.
- EQUIVOCADO - 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 (como 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 cuando se encuentran datos incompresibles es muy pequeña, y incremento el rendimiento de los datos típicos es significativo. Copiar una imagen de máquina virtual para una nueva instalación del sistema operativo Windows (SO recién instalado, sin datos aún) con compression=lz4 pasó un 27% más rápido que con compression=noneEn .
ARC: caché de reemplazo adaptable
ZFS es el único sistema de archivos moderno que conocemos que utiliza su propio mecanismo de almacenamiento en caché de lectura, en lugar de confiar en el caché de página del sistema operativo para almacenar copias de bloques leídos recientemente en la RAM.
Aunque la memoria caché nativa no está exenta 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 el nuevo desafío malloc() en la asignación de memoria puede fallar si necesita la RAM actualmente ocupada 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 (Usado menos recientemente) para implementar la caché de página. Este es un algoritmo primitivo que empuja el bloque almacenado en caché "hacia arriba en la cola" después de cada lectura, y empuja los bloques "hacia abajo en la cola" según sea necesario para agregar nuevos errores de caché (bloques que deberían haberse leído desde el disco, no desde el caché) arriba.
El algoritmo generalmente funciona bien, pero en sistemas con grandes conjuntos de datos de trabajo, LRU conduce fácilmente a la paliza, desalojando los bloques que se necesitan con frecuencia para dejar espacio para los bloques que nunca se volverán a leer de la memoria caché.
es un algoritmo mucho menos ingenuo que se puede considerar como un caché "ponderado". Cada vez que se lee un bloque almacenado en caché, se vuelve un poco "más pesado" y más difícil de desalojar, e incluso después de desalojar un bloque rastreado dentro de un cierto período de tiempo. Un bloque que ha sido desalojado pero luego debe volver a leerse en el caché también se volverá "más pesado".
El resultado final de todo esto es una caché con una proporción de aciertos mucho mayor, la proporción entre aciertos de caché (lecturas realizadas desde el caché) y errores de caché (lecturas desde el disco). Esta es una estadística extremadamente importante: no solo los aciertos de caché se atienden mucho más rápido, los errores de caché también se pueden atender más rápido, ya que cuantos más aciertos de caché, menos solicitudes de disco concurrentes y menor es la latencia para los errores restantes que deben ser servido con disco.
Conclusión
Después de aprender la semántica básica de ZFS (cómo funciona la copia en escritura, así como las relaciones entre grupos de almacenamiento, dispositivos virtuales, bloques, sectores y archivos), estamos listos para analizar el rendimiento del mundo real con números reales.
En la siguiente parte, veremos el rendimiento real de los grupos con vdevs duplicados y RAIDz, entre sí, y también en comparación con las topologías RAID del kernel de Linux tradicionales que hemos explorado. .
Al principio, queríamos cubrir solo los aspectos básicos, las topologías ZFS en sí mismas, pero después tales preparémonos para hablar sobre la configuración y el ajuste más avanzados de ZFS, incluido el uso de tipos de vdev auxiliares como L2ARC, SLOG y asignación especial.
Fuente: habr.com