Esta primavera xa comentamos algúns temas introdutorios, p. и . No segundo deles, incluso prometemos seguir estudando o rendemento de varias topoloxías multidisco en ZFS. Este é o sistema de ficheiros de próxima xeración que agora se está implantando en todas partes para .
Ben, hoxe é o mellor día para familiarizarse con ZFS, lectores curiosos. Só ten que saber que na humilde valoración do desarrollador de OpenZFS Matt Ahrens, "é moi difícil".
Pero antes de chegar aos números -e haberá, prometo- para todas as variantes da configuración ZFS de oito discos, temos que falar de como En xeral, ZFS almacena datos no disco.
Zpool, vdev e dispositivo
Este diagrama completo inclúe tres vdevs auxiliares, un de cada clase e catro para RAIDz2
Normalmente non hai ningunha razón para crear un conxunto de tipos e tamaños de vdev non coincidentes, pero se queres, nada che impida facelo
Para comprender realmente o sistema de ficheiros ZFS, cómpre observar a súa estrutura real. En primeiro lugar, ZFS unifica as capas tradicionais de xestión do volume e do sistema de ficheiros. En segundo lugar, usa un mecanismo transaccional de copia en escritura. Estas características significan que o sistema é estruturalmente moi diferente dos sistemas de ficheiros convencionais e das matrices RAID. O primeiro conxunto de bloques básicos a comprender son a agrupación de almacenamento (zpool), o dispositivo virtual (vdev) e o dispositivo real (dispositivo).
zpool
A agrupación de almacenamento zpool é a estrutura ZFS superior. Cada grupo contén un ou máis dispositivos virtuais. Á súa vez, cada un deles contén un ou máis dispositivos (dispositivos) reais. As piscinas virtuais son unidades autónomas. Un ordenador físico pode conter dous ou máis grupos separados, pero cada un é completamente independente dos outros. Os pools non poden compartir dispositivos virtuais.
A redundancia ZFS está a nivel de dispositivo virtual, non a nivel de grupo. Non hai absolutamente ningunha redundancia a nivel de grupo; se se perde un vdev ou un vdev dedicado, pérdese o conxunto completo xunto con el.
As agrupacións de almacenamento modernas poden sobrevivir á perda da caché ou do rexistro dun dispositivo virtual, aínda que poden perder unha pequena cantidade de datos sucios se perden o rexistro de vdev durante un corte de enerxía ou un fallo do sistema.
Hai unha idea errónea común de que as "strias de datos" de ZFS están escritas en todo o grupo. Isto non é certo. Zpool non é un RAID0 divertido, é máis divertido cun mecanismo complexo de distribución variable.
Na súa maior parte, os rexistros distribúense entre os dispositivos virtuais dispoñibles segundo o espazo libre dispoñible, polo que en teoría se encherán todos ao mesmo tempo. As versións máis recentes de ZFS teñen en conta o uso actual de vdev (eliminación): se un dispositivo virtual está significativamente máis ocupado que outro (por exemplo, debido á carga de lectura), omitirase temporalmente para as escrituras, a pesar de ter a maior proporción de espazo libre. .
O mecanismo de detección de reciclaxe integrado nos modernos métodos de asignación de escritura ZFS pode reducir a latencia e aumentar o rendemento durante períodos de carga inusualmente alta, pero non o fai. carta branca á mestura involuntaria de discos duros lentos e SSD rápidos nun único grupo. Unha piscina tan desigual aínda funcionará á velocidade do dispositivo máis lento, é dicir, coma se estivese integrada enteiramente por tales dispositivos.
vdev
Cada grupo de almacenamento consta dun ou máis dispositivos virtuais (vdev). Á súa vez, cada vdev inclúe un ou máis dispositivos reais. A maioría dos dispositivos virtuais úsanse para almacenar datos sinxelos, pero hai varias clases auxiliares de vdev, incluíndo CACHE, LOG e SPECIAL. Cada un destes tipos de vdev pode ter unha das cinco topoloxías: dispositivo único, RAIDz1, RAIDz2, RAIDz3 ou espello.
RAIDz1, RAIDz2 e RAIDz3 son variedades especiais do que os vellos chamarían RAID de paridade dobre (diagonal). 1, 2 e 3 refírense a cantos bloques de paridade están asignados a cada pista de datos. En lugar de ter discos separados para proporcionar paridade, os dispositivos RAIDz virtuais distribúen a paridade de forma semi-uniforme entre os discos. Unha matriz RAIDz pode perder tantos discos como bloques de paridade; se perde outro, fallará e levará consigo a agrupación de almacenamento.
Nos dispositivos virtuais espello (mirror vdev), cada bloque gárdase en cada dispositivo do vdev. Aínda que os espellos de dous anchos son os máis comúns, un espello pode conter calquera número arbitrario de dispositivos; en grandes instalacións, adoitan empregarse triplos para mellorar o rendemento de lectura e a tolerancia a fallos. Un espello de vdev pode sobrevivir a calquera fallo sempre que polo menos un dispositivo do vdev siga operativo.
Os vdev únicos son inherentemente perigosos. Tal dispositivo virtual non sobrevivirá a un único fallo e, se se usa como almacenamento ou como vdev especial, o seu fallo levará á destrución de todo o grupo. Teña moito, moito coidado aquí.
Pódense crear dispositivos virtuais CACHE, LOG e ESPECIAL en calquera das topoloxías anteriores, pero lembre que perder un dispositivo virtual ESPECIAL significa perder o grupo, polo que é moi recomendable unha topoloxía redundante.
dispositivo
Este é probablemente o termo máis fácil de entender en ZFS: é literalmente un dispositivo de acceso aleatorio de bloques. Lembra que os dispositivos virtuais están formados por dispositivos individuais e un grupo está formado por dispositivos virtuais.
Os discos, xa sexan magnéticos ou de estado sólido, son os dispositivos de bloques máis comúns utilizados como bloques de construción de vdev. Non obstante, calquera dispositivo cun descritor en /dev fará, polo que as matrices RAID de hardware enteiras poden usarse como dispositivos separados.
Un ficheiro en bruto simple é un dos dispositivos de bloque alternativos máis importantes desde os que se pode construír un vdev. Piscinas de proba de é un xeito moi cómodo de comprobar os comandos do pool e ver canto espazo hai dispoñible nun pool ou dispositivo virtual dunha determinada topoloxía.
Podes crear un grupo de probas a partir de ficheiros escasos en só uns segundos, pero despois non te esquezas de eliminar todo o grupo e os seus compoñentes.
Digamos que quere un servidor de oito discos e planea usar discos de 10 TB (~9300 GiB), pero non está seguro de cal é a topoloxía que mellor se adapta ás súas necesidades. No exemplo anterior, construímos un grupo de probas a partir de ficheiros escasos en cuestión de segundos, e agora sabemos que un vdev RAIDz2 de oito discos de 10 TB proporciona 50 TiB de capacidade utilizable.
Outra clase especial de dispositivos é SPARE. Os dispositivos de intercambio en quente, a diferenza dos dispositivos normais, pertencen a todo o grupo e non a un único dispositivo virtual. Se algún vdev do grupo falla e un dispositivo de reserva está conectado ao pool e dispoñible, entón unirase automaticamente ao vdev afectado.
Unha vez conectado ao vdev afectado, o dispositivo de substitución comeza a recibir copias ou reconstrucións dos datos que deberían estar no dispositivo que falta. No RAID tradicional isto chámase "reconstrución", e en ZFS é "resilvering".
É importante ter en conta que os dispositivos de substitución non substitúen permanentemente os dispositivos que fallan. Esta é só unha substitución temporal para reducir o tempo que tarda en degradarse vdev. Despois de que o administrador substitúa o dispositivo vdev fallido, restablece a redundancia nese dispositivo permanente e SPARE desconéctase do vdev e volve ser un recambio para todo o grupo.
Conxuntos de datos, bloques e sectores
O seguinte conxunto de bloques de construción que hai que entender na nosa viaxe a ZFS están menos relacionados co hardware e máis que ver coa forma en que se organizan e almacenan os datos. Saltamos algunhas capas aquí, como metaslab, para evitar desordenar os detalles mentres mantemos unha comprensión da estrutura xeral.
Conxunto de datos
Cando creamos por primeira vez un conxunto de datos, mostra todo o espazo dispoñible da piscina. Despois establecemos a cota e cambiamos o punto de montaxe. ¡Maxia!
Zvol é principalmente só un conxunto de datos eliminado da súa capa de sistema de ficheiros, que substituímos aquí por un sistema de ficheiros ext4 completamente normal.
O conxunto de datos ZFS é aproximadamente o mesmo que un sistema de ficheiros montado estándar. Como un sistema de ficheiros normal, a primeira vista parece ser "só outro cartafol". Pero do mesmo xeito que os sistemas de ficheiros montados habituais, cada conxunto de datos ZFS ten o seu propio conxunto de propiedades básicas.
En primeiro lugar, un conxunto de datos pode ter unha cota asignada. Se instalas zfs set quota=100G poolname/datasetname, entón non poderás escribir no cartafol montado /poolname/datasetname máis de 100 GiB.
Observa a presenza -e a ausencia- de barras inclinadas ao comezo de cada liña? Cada conxunto de datos ten o seu propio lugar tanto na xerarquía ZFS como na xerarquía de montaxe do sistema. Non hai ningunha barra inclinada na xerarquía ZFS: comeza co nome do grupo e despois o camiño dun conxunto de datos ao seguinte. Por exemplo, pool/parent/child para un conxunto de datos denominado child baixo o conxunto de datos principal parent nunha piscina cun nome creativo pool.
De forma predeterminada, o punto de montaxe dun conxunto de datos será equivalente ao seu nome na xerarquía ZFS, cunha barra inclinada inicial: o grupo chamado pool montado como /pool, conxunto de datos parent montado en /pool/parent, e o conxunto de datos secundarios child montado en /pool/parent/child. Non obstante, pódese cambiar o punto de montaxe do sistema do conxunto de datos.
Se indicamos zfs set mountpoint=/lol pool/parent/child, despois o conxunto de datos pool/parent/child montado no sistema como /lol.
Ademais dos conxuntos de datos, debemos mencionar os volumes (zvols). Un volume é aproximadamente o mesmo que un conxunto de datos, excepto que en realidade non ten un sistema de ficheiros, é só un dispositivo de bloque. Podes crear, por exemplo zvol Con nome mypool/myzvol, despois formatao cun sistema de ficheiros ext4 e, a continuación, monte ese sistema. Agora tes un sistema de ficheiros ext4, pero con todas as funcións de seguridade de ZFS. Isto pode parecer unha tontería nun ordenador, pero ten moito máis sentido como backend ao exportar un dispositivo iSCSI.
Bloques
Un ficheiro está representado por un ou máis bloques. Cada bloque gárdase nun dispositivo virtual. O tamaño do bloque adoita ser igual ao parámetro tamaño de rexistro, pero pódese reducir a 2^a quenda, se contén metadatos ou un ficheiro pequeno.
Nós realmente realmente Non estamos bromeando coa enorme penalización de rendemento se estableces un cambio demasiado baixo
Nun grupo ZFS, todos os datos, incluídos os metadatos, almacénanse en bloques. O tamaño máximo de bloque para cada conxunto de datos defínese na propiedade recordsize (tamaño do rexistro). O tamaño do rexistro pode cambiar, pero isto non cambiará o tamaño nin a localización dos bloques que xa se escribiron no conxunto de datos; só afecta aos bloques novos mentres se escriben.
A menos que se especifique o contrario, o tamaño de entrada predeterminado actual é de 128 KiB. É unha especie de compromiso difícil onde o rendemento non será perfecto, pero non será terrible na maioría dos casos. Recordsize pódese configurar en calquera valor de 4K a 1M (con configuracións adicionais recordsize pode instalar aínda máis, pero esta raramente é unha boa idea).
Calquera bloque refírese aos datos dun só ficheiro; non podes espremer dous ficheiros diferentes nun bloque. Cada ficheiro consta dun ou máis bloques, dependendo do seu tamaño. Se o tamaño do ficheiro é menor que o tamaño do rexistro, almacenarase nun bloque máis pequeno; por exemplo, un bloque cun ficheiro de 2 KiB só ocupará un sector de 4 KiB no disco.
Se o ficheiro é o suficientemente grande como para requirir varios bloques, todas as entradas dese ficheiro terán un tamaño recordsize - incluíndo a última entrada, cuxa parte principal pode ser .
os volumes zvol non teñen a propiedade recordsize - en cambio teñen a propiedade equivalente volblocksize.
Sectores
O último e máis básico bloque é o sector. É a unidade física máis pequena que se pode escribir ou ler desde un dispositivo host. Durante varias décadas, a maioría dos discos utilizaron sectores de 512 bytes. Hoxe en día, a maioría das unidades están configuradas para sectores de 4 KiB, e algunhas, especialmente as SSD, están configuradas para sectores de 8 KiB ou incluso máis grandes.
ZFS ten unha función que che permite configurar manualmente o tamaño do sector. Esta propiedade ashift. De forma algo confusa, o cambio é un poder de dous. Por exemplo, ashift=9 significa o tamaño do sector 2^9 ou 512 bytes.
ZFS pídelle ao sistema operativo información detallada sobre cada dispositivo de bloque cando se engade a un novo vdev e, teoricamente, axusta automaticamente o cambio en función desa información. Desafortunadamente, moitas unidades minten sobre o tamaño do seu sector para manter a compatibilidade con Windows XP (que non puido entender as unidades con outros tamaños de sector).
Isto significa que é moi recomendable que o administrador de ZFS coñeza o tamaño real do sector dos seus dispositivos e o configure manualmente ashift. Se o ashift é demasiado pequeno, o número de operacións de lectura/escritura aumenta astronómicamente. Entón, escribir "sectores" de 512 bytes nun sector real de 4 KiB significa ter que escribir o primeiro "sector", despois ler o sector de 4 KiB, modificalo cun segundo "sector de 512 bytes", escribir de novo no novo sector. Sector de 4 KiB, etc. para cada entrada.
No mundo real, tal penalización afecta aos SSD EVO de Samsung, para os que debería aplicarse ashift=13, pero estes SSD atópanse sobre o tamaño do seu sector e, polo tanto, o valor predeterminado está definido como ashift=9. A menos que un administrador do sistema experimentado cambie esta configuración, este SSD funciona máis lento disco duro magnético normal.
Por comparación, por ser demasiado grande ashift practicamente non hai penalización. Non hai un éxito de rendemento real e o aumento do espazo non utilizado é infinitesimal (ou cero se a compresión está activada). Polo tanto, recomendamos encarecidamente que se instalen incluso aquelas unidades que usan sectores de 512 bytes ashift=12 ou mesmo ashift=13para mirar con confianza cara ao futuro.
Propiedade ashift está instalado para cada dispositivo virtual vdev, e non para piscina, como moita xente pensa erróneamente - e non cambia despois da instalación. Se golpeas accidentalmente ashift Cando engades un novo vdev a unha piscina, contaminaches esa piscina irrevocablemente cun dispositivo de baixo rendemento e, por regra xeral, non hai outra opción que destruír a piscina e comezar de novo. Incluso eliminando vdev non che salvará dunha configuración rota ashift!
Mecanismo de copia sobre escritura
Se un sistema de ficheiros normal necesita reescribir datos, modifica cada bloque onde se atopa
Un sistema de ficheiros de copia en escritura escribe unha nova versión do bloque e despois desbloquea a versión antiga
En resumo, se ignoramos a disposición física real dos bloques, o noso "cometa de datos" simplifícase a un "verme de datos" que se move de esquerda a dereita polo mapa do espazo dispoñible.
Agora podemos ter unha boa idea de como funcionan as instantáneas de copia en escritura: cada bloque pode pertencer a varias instantáneas e persistirá ata que se destrúan todas as instantáneas asociadas.
O mecanismo Copy on Write (CoW) é a base fundamental do que fai de ZFS un sistema tan sorprendente. O concepto básico é sinxelo: se lle pide a un sistema de ficheiros tradicional que cambie un ficheiro, fará exactamente o que lle pediu. Se lle pide a un sistema de ficheiros de copia en escritura que faga o mesmo, dirá "está ben", pero mentirache.
Pola contra, un sistema de ficheiros de copia en escritura escribe unha nova versión do bloque modificado e, a continuación, actualiza os metadatos do ficheiro para desvincular o bloque antigo e asocialo co novo bloque que acaba de escribir.
Desvincular o bloque antigo e ligar o novo realízase nunha soa operación, polo que non se pode interromper; se restablece a alimentación despois de que isto suceda, ten unha nova versión do ficheiro e, se restablece a enerxía antes, entón terá a versión antiga. En calquera caso, non haberá conflitos no sistema de ficheiros.
A copia en escritura en ZFS ocorre non só a nivel de sistema de ficheiros, senón tamén a nivel de xestión de discos. Isto significa que ZFS non é susceptible a espazos en branco no rexistro () - un fenómeno no que a tira só se gravara parcialmente antes de que o sistema fallase, con danos na matriz despois dun reinicio. Aquí a raia escríbese atomicamente, vdev sempre é secuencial e .
ZIL: rexistro de intencións de ZFS
ZFS xestiona as escrituras síncronas dun xeito especial: gárdaas temporalmente pero inmediatamente en ZIL antes de escribirlas de forma permanente xunto coas escrituras asíncronas.
Normalmente, os datos escritos en ZIL nunca se volven ler. Pero isto é posible despois dun fallo do sistema
Un SLOG, ou dispositivo LOG secundario, é simplemente un vdev especial, e preferiblemente moi rápido, onde o ZIL se pode almacenar por separado do almacenamento principal.
Despois dun fallo, todos os datos sucios en ZIL reprodúcense; neste caso, ZIL está en SLOG, polo que aí é onde se reproducen.
Existen dúas categorías principais de escrituras: síncronas (sincrónicas) e asíncronas (asíncronas). Para a maioría das cargas de traballo, a gran maioría das escrituras son asíncronas: o sistema de ficheiros permite que se agreguen e emitan por lotes, reducindo a fragmentación e aumentando significativamente o rendemento.
As gravacións sincrónicas son unha cuestión completamente diferente. Cando unha aplicación solicita unha escritura sincrónica, dille ao sistema de ficheiros: "Necesitas confirmar isto na memoria non volátil. agora, e ata entón non teño máis que facer”. Polo tanto, as escrituras síncronas deben comprometerse no disco inmediatamente, e se isto aumenta a fragmentación ou reduce o rendemento, así sexa.
ZFS manexa as escrituras síncronas de forma diferente que os sistemas de ficheiros normais; en lugar de laxalas inmediatamente ao almacenamento normal, ZFS contribúeas a unha área de almacenamento especial chamada ZFS Intent Log ou ZIL. O truco é que estes rexistros tamén permanecen na memoria, sendo agregados xunto coas solicitudes de escritura asíncronas normais, para posteriormente ser descargados no almacenamento como TXG (grupos de transaccións) completamente normais.
Durante o funcionamento normal, ZIL escríbese e nunca se volve a ler. Cando, despois duns momentos, os rexistros do ZIL están comprometidos no almacenamento principal en TXG habituais da memoria RAM, desvinculanse do ZIL. A única vez que se le algo de ZIL é ao importar un grupo.
Se se produce un fallo de ZFS (un fallo do sistema operativo ou un corte de enerxía) mentres hai datos no ZIL, eses datos leranse durante a próxima importación do grupo (por exemplo, cando se reinicie o sistema de conmutación por fallo). O que estea no ZIL será lido, agrupado en TXG, comprometido na tenda principal e, a continuación, desvinculado do ZIL durante o proceso de importación.
Unha das clases auxiliares de vdev chámase LOG ou SLOG, un dispositivo LOG secundario. Ten unha tarefa: proporcionar unha piscina cun dispositivo vdev separado e, preferiblemente, moito máis rápido, cunha resistencia á escritura moi alta para almacenar ZIL, en lugar de almacenar ZIL no almacenamento vdev principal. O propio ZIL se comporta igual independentemente da localización de almacenamento, pero se o vdev con LOG ten un rendemento de escritura moi alto, entón as escrituras sincrónicas serán máis rápidas.
Engadir vdev con LOG ao grupo non funciona non podo mellorar o rendemento de escritura asíncrona, aínda que forzas todas as escrituras en ZIL zfs set sync=always, seguirán ligados ao almacenamento principal en TXG do mesmo xeito e ao mesmo ritmo que sen o rexistro. A única mellora directa do rendemento é a latencia de escritura sincrónica (xa que as velocidades de rexistro máis altas fan que as operacións sexan máis rápidas sync).
Non obstante, nun ambiente que xa require moitas escrituras síncronas, vdev LOG pode acelerar indirectamente as escrituras asíncronas e as lecturas sen caché. A descarga de rexistros ZIL nun LOG de vdev separado significa menos disputas para IOPS no almacenamento principal, o que mellora o rendemento de todas as lecturas e escrituras ata certo punto.
Instantáneas
O mecanismo de copia en escritura tamén é unha base necesaria para as instantáneas atómicas de ZFS e a replicación asíncrona incremental. O sistema de ficheiros activo ten unha árbore de punteiros que marca todas as entradas cos datos actuais; cando fas unha instantánea, simplemente fai unha copia desta árbore de punteiros.
Cando se sobrescribe un rexistro no sistema de ficheiros activo, ZFS escribe primeiro a nova versión do bloque no espazo non utilizado. A continuación, separa a versión antiga do bloque do sistema de ficheiros actual. Pero se algunha instantánea fai referencia a un bloque antigo, aínda permanece sen cambios. O bloque antigo non se restaurará como espazo libre ata que se destrúan todas as instantáneas que fan referencia a ese bloque.
Replicación
A miña biblioteca de Steam en 2015 era de 158 GiB e incluía 126 ficheiros. Isto está bastante preto da situación óptima para rsync: a replicación de ZFS na rede foi "só" un 927 % máis rápida.
Na mesma rede, replicar un único ficheiro de imaxe de máquina virtual Windows 40 de 7 GB é unha historia completamente diferente. A replicación ZFS é 289 veces máis rápida que rsync, ou "só" 161 veces máis rápida se tes o suficiente coñecemento para chamar a rsync co interruptor --inplace.
Cando unha imaxe de VM escala, rsync problemas con ela. O tamaño de 1,9 TiB non é tan grande para unha imaxe de VM moderna, pero é o suficientemente grande como para que a replicación ZFS sexa 1148 veces máis rápida que rsync, mesmo co argumento rsync --inplace
Unha vez que entendas como funcionan as instantáneas, será fácil comprender a esencia da replicación. Dado que unha instantánea é simplemente unha árbore de apuntadores de rexistro, dedúcese que se o facemos zfs send instantánea, entón enviamos esta árbore e todos os rexistros asociados a ela. Cando pasemos isto zfs send в zfs receive no obxecto de destino, escribe tanto o contido real do bloque como a árbore de punteiros que fai referencia aos bloques ao conxunto de datos de destino.
As cousas fanse aínda máis interesantes no segundo zfs send. Agora temos dous sistemas, cada un contén poolname/datasetname@1, e tiras unha nova instantánea poolname/datasetname@2. Polo tanto, no pool de orixe que tes datasetname@1 и datasetname@2, e no grupo de destino só hai a primeira instantánea datasetname@1.
Porque entre a fonte e o destino temos unha instantánea común datasetname@1, podemos facelo incremental zfs send enriba dela. Cando lle contamos ao sistema zfs send -i poolname/datasetname@1 poolname/datasetname@2, compara dúas árbores de punteiros. Calquera punteiro que só exista en @2, obviamente refírense a novos bloques, polo que necesitaremos o contido deses bloques.
Nun sistema remoto, procesamento incremental send igual de sinxelo. Primeiro escribimos todas as novas entradas incluídas no fluxo send, e despois engade punteiros a estes bloques. Voila, temos @2 no novo sistema!
A replicación incremental asíncrona ZFS é unha gran mellora con respecto a métodos anteriores non baseados en instantáneas, como rsync. En ambos os casos, só se transfiren os datos modificados, pero rsync debe primeiro ler do disco todos os datos de ambos os dous lados para comprobar a suma e comparala. Pola contra, a replicación ZFS non le nada máis que árbores de punteiros e calquera bloque que non estea representado na instantánea xeral.
Compresión incorporada
O mecanismo de copia sobre escritura tamén simplifica o sistema de compresión integrado. Nun sistema de ficheiros tradicional, a compresión é problemática: tanto a versión antiga como a nova dos datos modificados están no mesmo espazo.
Se consideras un dato no medio dun ficheiro que comeza a súa vida como un megabyte de ceros a partir de 0x00000000 e así por diante, é moi sinxelo comprimilo nun único sector do disco. Pero que pasa se substituímos este megabyte de ceros por un megabyte de datos incompresibles, como JPEG ou ruído pseudoaleatorio? De súpeto, ese megabyte de datos requiriría non un, senón 256 sectores de 4 KiB, e só se reservou un sector nese espazo de disco.
ZFS non ten este problema, xa que os rexistros modificados sempre se escriben no espazo non utilizado - o bloque orixinal só ocupa un sector de 4 KiB e unha nova escritura ocupará 256, pero isto non é un problema - un fragmento modificado recentemente de o "medio" do ficheiro escribiríase no espazo non utilizado independentemente de se o seu tamaño cambiou ou non, polo que esta é unha situación completamente normal para ZFS.
A compresión ZFS integrada está desactivada de forma predeterminada e o sistema ofrece algoritmos conectables, que inclúen actualmente LZ4, gzip (1-9), LZJB e ZLE.
- LZ4 é un algoritmo de transmisión que ofrece compresión e descompresión extremadamente rápidas e beneficios de rendemento para a maioría dos casos de uso, incluso en CPU bastante lentas.
- GZIP é un algoritmo venerable que todos os usuarios de Unix coñecen e adoran. Pódese implementar cos niveis de compresión 1-9, aumentando a relación de compresión e o uso da CPU a medida que se achega ao nivel 9. O algoritmo é moi axeitado para todos os casos de uso de texto (ou outros altamente comprimibles), pero moitas veces causa problemas de CPU doutro xeito - utilízao. con precaución, especialmente nos niveis superiores.
- LZJB - algoritmo orixinal en ZFS. Está obsoleto e xa non se debe usar, LZ4 é superior en todos os sentidos.
- MAL — Codificación de nivel cero, Codificación de nivel cero. Non toca datos normais en absoluto, pero comprime grandes secuencias de ceros. Útil para conxuntos de datos totalmente incomprimibles (como JPEG, MP4 ou outros formatos xa comprimidos), xa que ignora os datos incomprimibles pero comprime o espazo non utilizado nos rexistros resultantes.
Recomendamos a compresión LZ4 para case todos os casos de uso; a penalización de rendemento ao tratar con datos incomprimibles é moi pequena, e crecemento o rendemento dos datos típicos é significativo. Copiando unha imaxe de máquina virtual para unha nova instalación do sistema operativo Windows (sistema operativo recén instalado, aínda non hai datos) con compression=lz4 pasou un 27% máis rápido que con compression=noneEn .
ARC - caché de substitución adaptativa
ZFS é o único sistema de ficheiros moderno que coñecemos que usa o seu propio mecanismo de caché de lectura, en lugar de depender da caché de páxinas do sistema operativo para almacenar copias dos bloques lidos recentemente na RAM.
Aínda que a caché nativa non está exenta de problemas - ZFS non pode responder ás novas solicitudes de asignación de memoria tan rápido como o núcleo, polo que unha nova chamada malloc() A asignación de memoria pode fallar se require RAM ocupada actualmente por ARC. Pero hai boas razóns para usar a túa propia caché, polo menos polo momento.
Todos os sistemas operativos modernos coñecidos, incluídos MacOS, Windows, Linux e BSD, usan o algoritmo LRU (Usado Menor) para implementar a caché de páxinas. Este é un algoritmo primitivo que empurra un bloque almacenado na caché "ao principio da cola" despois de cada lectura e empurra os bloques "ao final da cola" segundo sexa necesario para engadir novos erros de caché (bloques que deberían ser lidos desde o disco en lugar de desde a caché) ata a parte superior.
Normalmente, o algoritmo funciona ben, pero en sistemas con grandes conxuntos de datos de traballo, a LRU conduce facilmente a derramar, eliminando os bloques que se necesitan con frecuencia para deixar espazo para os bloques que nunca se volverán ler da caché.
é un algoritmo moito menos inxenuo que se pode considerar unha caché "ponderada". Cada vez que se le un bloque almacenado en caché, faise un pouco máis pesado e máis difícil de expulsar, e mesmo despois de que o bloque sexa expulsado rastrexado durante un determinado período de tempo. Un bloque que foi desaloxado pero que despois hai que ler de novo na caché tamén se fará máis pesado.
O resultado final de todo isto é unha caché cunha proporción de acertos moito máis alta: a proporción entre as acertos da caché (lecturas da caché) e os erros (lecturas do disco). Esta é unha estatística extremadamente importante: non só as acertos de caché son atendidos en ordes de magnitude máis rápido, os fallos de caché tamén poden ser atendidos máis rápido, xa que cantos máis acertos de caché haxa, menos solicitudes paralelas no disco e menor será a latencia dos fallos restantes. que debe ser atendido con disco.
Conclusión
Agora que cubrimos a semántica básica de ZFS (como funciona a copia en escritura, así como as relacións entre grupos de almacenamento, dispositivos virtuais, bloques, sectores e ficheiros), estamos preparados para discutir o rendemento no mundo real con números reais.
Na seguinte parte, analizaremos o rendemento real dos conxuntos de vdev e RAIDz reflectidos, en comparación entre si, e tamén en comparación coas topoloxías RAID tradicionais do núcleo de Linux que examinamos. .
Ao principio queriamos cubrir só os conceptos básicos - as propias topoloxías ZFS - pero despois tal Estaremos preparados para falar de configuración e axuste máis avanzado de ZFS, incluíndo o uso de tipos de vdev auxiliares como L2ARC, SLOG e Special Allocation.
Fonte: www.habr.com