Nesta primavera, já discutimos alguns tópicos introdutórios, como verificar a velocidade de suas unidades e o que é RAID . No segundo deles, prometemos continuar estudando o desempenho de várias topologias de vários discos no ZFS. Este é o sistema de arquivos da próxima geração que está sendo implementado em qualquer lugar: da Apple ao Ubuntu .

Bem, hoje é o melhor dia para conhecer o ZFS, leitores curiosos. Lembre-se de que, de acordo com uma avaliação conservadora do desenvolvedor do OpenZFS, Matt Arens, "é realmente complicado".

Mas antes de chegarmos aos números - e eles serão, prometo - para todas as variantes de configuração do ZFS vosmidiskovoy, é necessário falar sobre como fazer o ZFS armazena dados no disco.

Zpool, vdev e dispositivo

Esse diagrama completo do pool inclui três vdevs auxiliares, um para cada classe e quatro para o RAIDz2.Normalmente,

não há razão para criar um pool de tipos e tamanhos inadequados de vdev - mas, se você quiser, nada o impede de fazer isso.

Para realmente entender o sistema de arquivos ZFS , você precisa examinar atentamente sua estrutura real. Primeiro, o ZFS combina os níveis tradicionais de gerenciamento de volume e o sistema de arquivos. Em segundo lugar, ele usa um mecanismo de cópia transacional ao escrever. Esses recursos significam que o sistema é estruturalmente muito diferente dos sistemas de arquivos comuns e matrizes RAID. O primeiro conjunto de componentes básicos a serem entendidos: um pool de armazenamento (zpool), um dispositivo virtual (vdev) e um dispositivo real (dispositivo).

zpool

O pool de armazenamento zpool é a estrutura ZFS superior. Cada pool contém um ou mais dispositivos virtuais. Por sua vez, cada um deles contém um ou mais dispositivos reais (dispositivo). Pools virtuais são blocos autônomos. Um computador físico pode conter dois ou mais conjuntos separados, mas cada um é completamente independente dos outros. Os pools não podem compartilhar dispositivos virtuais.

A redundância do ZFS está no nível de dispositivos virtuais, mas não no nível de conjuntos. No nível do pool, não há absolutamente redundância - se alguma unidade vdev ou vdev especial for perdida, o pool inteiro será perdido junto com ele.

Os pools de armazenamento modernos podem sobreviver à perda de um cache ou log de dispositivo virtual - embora possam perder uma pequena quantidade de dados sujos se perderem o log do vdev durante uma queda de energia ou falha no sistema.

Existe um equívoco comum de que “faixas de dados” (tiras) do ZFS são registradas em todo o pool. Isso não é verdade. O Zpool não é um RAID0 divertido, é um JBOD divertido com um mecanismo de distribuição variável complexo.

Na maioria das vezes, as entradas são distribuídas entre os dispositivos virtuais disponíveis de acordo com o espaço disponível; portanto, teoricamente, todos serão preenchidos ao mesmo tempo. Nas versões posteriores do ZFS, o uso atual (utilização) do vdev é levado em consideração - se um dispositivo virtual for significativamente mais carregado que o outro (por exemplo, devido à carga de leitura), ele será temporariamente ignorado para gravação, apesar da presença do maior coeficiente de espaço livre.

Um mecanismo de detecção de reciclagem incorporado aos métodos modernos de distribuição de registros ZFS pode reduzir a latência e aumentar o rendimento durante períodos de carga extraordinariamente alta - mas isso não é uma carta brancainvoluntariamente misturando HDDs lentos e SSDs rápidos em um pool. Um pool tão desigual ainda funcionará na velocidade do dispositivo mais lento, ou seja, como se fosse inteiramente composto por esses dispositivos.

vdev

Cada conjunto de armazenamento consiste em um ou mais dispositivos virtuais (dispositivo virtual, vdev). Por sua vez, cada vdev inclui um ou mais dispositivos reais. A maioria dos dispositivos virtuais é usada para armazenar dados com facilidade, mas existem várias classes auxiliares vdev, incluindo CACHE, LOG e SPECIAL. Cada um desses tipos de vdev pode ter uma das cinco topologias: dispositivo único, RAIDz1, RAIDz2, RAIDz3 ou espelho.

RAIDz1, RAIDz2 e RAIDz3 são variações especiais do que os antigos chamam de paridade dupla (diagonal) RAID. 1, 2 e 3 se referem a quantos blocos de paridade estão alocados para cada banda de dados. Em vez de discos separados para paridade, os dispositivos RAIDz virtuais distribuem uniformemente essa paridade entre discos. Uma matriz RAIDz pode perder quantos discos tiver blocos de paridade; se ele perder outro, ele falhará e levará o pool de armazenamento com ele.

Nos dispositivos virtuais espelhados (mirror vdev), cada bloco é armazenado em cada dispositivo no vdev. Embora os espelhos de duas larguras mais comuns, possa haver qualquer número arbitrário de dispositivos no espelho - em grandes instalações, os triplos são frequentemente usados para aumentar o desempenho de leitura e a tolerância a falhas. O espelho vdev pode sobreviver a qualquer falha enquanto pelo menos um dispositivo no vdev continua funcionando.

Os vdevs únicos são inerentemente perigosos. Esse dispositivo virtual não sobreviverá a uma única falha - e se for usado como armazenamento ou um vdev especial, sua falha levará à destruição de todo o pool. Tenha muito, muito cuidado aqui.

Os dispositivos virtuais CACHE, LOG e SPECIAL podem ser criados usando qualquer uma das topologias acima - mas lembre-se de que perder um dispositivo virtual SPECIAL significa perder um pool; portanto, é altamente recomendável uma topologia excessiva.

dispositivo

Este é provavelmente o termo mais fácil de entender no ZFS - é literalmente um dispositivo de acesso aleatório em bloco. Lembre-se de que os dispositivos virtuais são compostos de dispositivos individuais e o pool é composto de dispositivos virtuais.

Discos - magnéticos ou de estado sólido - são os dispositivos de bloco mais comuns usados como blocos de construção do vdev. No entanto, qualquer dispositivo com um identificador em / dev é adequado - para que você possa usar matrizes RAID de hardware inteiras como dispositivos separados.

Um arquivo simples é um dos dispositivos de bloco alternativos mais importantes dos quais o vdev pode ser construído. Conjuntos de teste de arquivos esparsos - Uma maneira muito conveniente de verificar os comandos do pool e ver quanto espaço está disponível no pool ou no dispositivo virtual dessa topologia.

Você pode criar um pool de teste a partir de arquivos esparsos em apenas alguns segundos - mas não se esqueça de excluir o pool inteiro e seus componentes posteriormente.

Suponha que você queira colocar um servidor em oito discos e planeje usar discos de 10 TB (~ 9300 GiB) - mas não tem certeza de qual A topologia atende melhor às suas necessidades. No exemplo acima, em questão de segundos, criamos um pool de testes a partir de arquivos esparsos - e agora sabemos que o RAIDz2 vdev de oito unidades de 10 TB fornece 50 TiB de capacidade útil.

Outra classe especial de dispositivos é SOBRESSALENTE (sobressalente). Os dispositivos com troca a quente, diferentemente dos dispositivos convencionais, pertencem a todo o pool, não apenas a um dispositivo virtual. Se algum vdev no pool falhar e o dispositivo sobressalente estiver conectado e disponível, ele entrará automaticamente no vdev afetado.

Após conectar-se ao vdev afetado, o dispositivo sobressalente começa a receber cópias ou reconstrução de dados que devem estar no dispositivo ausente. No RAID tradicional, isso é chamado de reconstrução, enquanto no ZFS é chamado de "resilvering".

É importante observar que os dispositivos de substituição não substituem permanentemente os dispositivos com falha. Esta é apenas uma substituição temporária para reduzir o tempo durante o qual a degradação do vdev é observada. Depois que o administrador substituiu o dispositivo vdev com falha, a redundância é restaurada para esse dispositivo permanente e o SPARE se desconecta do vdev e volta a funcionar como um sobressalente para todo o pool.

Conjuntos de dados, blocos e setores

O próximo conjunto de blocos de construção que você precisa entender em nossa jornada pelo ZFS não é tanto hardware, mas como os dados são organizados e armazenados. Ignoramos vários níveis aqui - como o metaslab - para não acumular os detalhes, mantendo um entendimento da estrutura geral.

Conjunto de dados

Quando criamos um conjunto de dados, ele mostra todo o espaço disponível no pool. Em seguida, definimos a cota - e alteramos o ponto de montagem. Magia!

O Zvol é na maioria das vezes apenas um conjunto de dados, desprovido de sua camada de sistema de arquivos, que substituímos aqui por um

sistema de arquivos ext4 completamente normal.O conjunto de dados ZFS é aproximadamente o mesmo que um sistema de arquivos montado padrão. Como um sistema de arquivos comum, à primeira vista, parece ser "apenas outra pasta". Mas também, como sistemas de arquivos montados convencionais, cada conjunto de dados do ZFS possui seu próprio conjunto de propriedades básicas.

Primeiro de tudo, um conjunto de dados pode ter uma cota atribuída. Se instaladozfs set quota=100G poolname/datasetname, você não poderá gravar na pasta montada/poolname/datasetnamemais de 100 GiB.

Percebe a presença - e a ausência - de barras no início de cada linha? Cada conjunto de dados tem seu próprio lugar na hierarquia do ZFS e na hierarquia de montagem do sistema. Não há barra invertida na hierarquia do ZFS - você começa com o nome do pool e depois o caminho de um conjunto de dados para o próximo. Por exemplo, pool/parent/childpara um conjunto de dados nomeado childno conjunto de dados pai parentem um pool com um nome de criativo pool.

Por padrão, o ponto de montagem do conjunto de dados será equivalente ao seu nome na hierarquia ZFS, com uma barra no início - a piscina com o nome é poolmontado como /pool, o conjunto de dados é parentmontado em /pool/parent, ea criança conjunto de dados é montado childem /pool/parent/child. No entanto, o ponto de montagem do sistema para o conjunto de dados pode ser alterado.

Se indicarmoszfs set mountpoint=/lol pool/parent/child, o conjunto de dados é pool/parent/childmontado no sistema como /lol.

Além dos conjuntos de dados, devemos mencionar volumes (zvols). Um volume é aproximadamente semelhante a um conjunto de dados, exceto pelo fato de não possuir um sistema de arquivos - é apenas um dispositivo de bloco. Você pode, por exemplo, criar zvolcom um nome mypool/myzvol, formatá-lo com o sistema de arquivos ext4 e montar esse sistema de arquivos - agora você possui o sistema de arquivos ext4, mas com suporte para todos os recursos de segurança do ZFS! Isso pode parecer bobagem em um computador, mas faz muito mais sentido como back-end ao exportar um dispositivo iSCSI.

Blocos

Um arquivo é representado por um ou mais blocos. Cada bloco é armazenado em um dispositivo virtual. O tamanho do bloco geralmente é igual ao parâmetro recordsize , mas pode ser reduzido para 2 ^ ashift se contiver metadados ou um arquivo pequeno.

Realmente, não estamos brincando sobre o enorme dano no desempenho se você instalar um desvio muito pequeno

No pool do ZFS, todos os dados, incluindo metadados, são armazenados em blocos. O tamanho máximo do bloco para cada conjunto de dados é definido na propriedaderecordsize(tamanho do registro). O tamanho do registro pode variar, mas isso não altera o tamanho ou o local de nenhum bloco que já tenha sido gravado no conjunto de dados - ele é válido apenas para novos blocos à medida que são gravados.

Salvo indicação em contrário, o tamanho atual da gravação é 128 KiB por padrão. Esse é um tipo de compromisso difícil em que o desempenho não será ideal, mas não é terrível na maioria dos casos. Recordsizepode ser definido com qualquer valor de 4K a 1M (com configurações adicionais, recordsizevocê pode definir ainda mais, mas isso raramente é uma boa ideia).

Qualquer bloco refere-se aos dados de apenas um arquivo - você não pode espremer dois arquivos diferentes em um bloco. Cada arquivo consiste em um ou mais blocos, dependendo do tamanho. Se o tamanho do arquivo for menor que o tamanho do registro, ele será salvo em um bloco menor - por exemplo, um bloco com um arquivo de 2 KiB ocupará apenas um setor de 4 KiB no disco.

Se o arquivo for grande o suficiente e exigir vários blocos, todos os registros com esse arquivo terão um tamanhorecordsize - incluindo o último registro, cuja parte principal pode se tornar um espaço não utilizado .

Os volumes Zvol não têm uma propriedade recordsize - eles têm uma propriedade equivalente volblocksize.

Setores

O último bloco de construção mais básico é o setor. Essa é a menor unidade física que pode ser gravada ou lida na unidade base. Por várias décadas, a maioria dos discos usou setores de 512 bytes. Recentemente, a maioria das unidades está configurada para 4 setores KiB e, em alguns setores - especialmente SSDs - 8 KiB ou mais.

O ZFS possui uma propriedade que permite definir manualmente o tamanho do setor. Esta é uma propriedade ashift. É um pouco confuso que o desvio de dinheiro seja uma potência de dois. Por exemplo, ashift=9significa um tamanho de setor de 2 ^ 9 ou 512 bytes.

O ZFS solicita ao sistema operacional informações detalhadas sobre cada dispositivo de bloco quando ele é adicionado ao novo vdev e, teoricamente, define automaticamente o desvio corretamente com base nessas informações. Infelizmente, muitos discos mentem sobre o tamanho do setor para manter a compatibilidade com o Windows XP (que não conseguia entender discos com outros tamanhos de setor).

Isso significa que é recomendável que o administrador do ZFS conheça o tamanho real do setor de seus dispositivos e instale manualmenteashift. Se um ashift muito pequeno for definido, o número de operações de leitura / gravação aumentará astronomicamente. Portanto, escrever "setores" de 512 bytes no setor real de 4 KiB significa escrever o primeiro "setor", depois ler o setor de 4 KiB, alterá-lo com o segundo "setor" de 512 bytes, gravá-lo no novo setor de 4 KiB e assim por diante para cada entrada.

No mundo real, essa penalidade supera os ashift=13SSDs Samsung EVO, pelos quais deve agir , mas esses SSDs se referem ao tamanho do setor e, portanto, são definidos por padrão ashift=9. Se um administrador de sistema experiente não alterar essa configuração, esse SSD será mais lento que um HDD magnético comum.

Para comparação, para um tamanho muito grandeashiftpraticamente não há penalidade. Não há redução real da produtividade e o aumento do espaço não utilizado é infinitamente pequeno (ou igual a zero com a compactação ativada). Portanto, é altamente recomendável que mesmo as unidades que realmente usam setores de 512 bytes sejam instaladas ashift=12ou ashift=13que olhem com confiança para o futuro.

A propriedade é ashiftconfigurada para cada dispositivo virtual vdev, e não para o pool , como muitos pensam erroneamente - e não muda após a instalação. Se você acidentalmente derrubou ashiftao adicionar um novo vdev à piscina, contaminou-a irrevogavelmente com um dispositivo de baixo desempenho e, como regra, não há outra maneira senão destruir a piscina e começar tudo de novo. Mesmo remover o vdev não salvará você de uma instalação corrompidaashift!

— ,

, , « » « »,

, — , ,

O Copy on Write (CoW) é a base fundamental do que torna o ZFS tão impressionante. O conceito básico é simples - se você pedir ao sistema de arquivos tradicional para modificar o arquivo, ele fará exatamente o que você solicitou. Se você pedir ao sistema de arquivos com cópia durante a gravação que faça o mesmo, será exibido "bom" - mas será uma mentira para você.

Em vez disso, o sistema de arquivos de cópia / gravação grava a nova versão do bloco modificado e atualiza os metadados do arquivo para quebrar o vínculo com o bloco antigo e associar o novo bloco que você acabou de escrever.

Desconectar a unidade antiga e vincular a nova é feita em uma operação, para que não possa ser interrompida - se você reiniciar a energia após isso acontecer, você terá uma nova versão do arquivo e, se reiniciar a energia mais cedo, terá a versão antiga. De qualquer forma, não haverá conflito no sistema de arquivos.

A cópia ao gravar no ZFS ocorre não apenas no nível do sistema de arquivos, mas também no nível de gerenciamento de disco. Isso significa que o ZFS não está sujeito a um espaço no registro (um buraco no RAID ) - um fenômeno em que a faixa conseguiu gravar parcialmente antes de o sistema travar, com a matriz danificada após uma reinicialização. Aqui a tira é atômica, vdev é sempre consistente e Bob é seu tio .

ZIL: log de intenção do ZFS

ZFS — , ZIL,

, ZIL, .

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

ZIL — ZIL SLOG,

Existem duas categorias principais de operações de gravação - síncrona (sincronização) e assíncrona (assíncrona). Para a maioria das cargas de trabalho, a grande maioria das operações de gravação é assíncrona - o sistema de arquivos permite agregá-las e entregá-las em lotes, reduzindo a fragmentação e aumentando significativamente a taxa de transferência.

Gravações síncronas são uma questão completamente diferente. Quando um aplicativo solicita uma gravação síncrona, ele diz ao sistema de arquivos: "Você precisa confirmar isso na memória não volátil no momento e até então não posso fazer mais nada". Portanto, gravações síncronas devem ser imediatamente confirmadas no disco - e se isso aumenta a fragmentação ou reduz a largura de banda, o mesmo acontece.

O ZFS processa registros síncronos de maneira diferente dos sistemas de arquivos comuns - em vez de enviá-los imediatamente para o armazenamento regular, o ZFS os grava em uma área de armazenamento especial chamada log de intenção do ZFS - ZFS Intent Log ou ZIL. O truque é que esses registros também permanecem na memória, sendo agregados juntamente com solicitações regulares de gravação assíncrona, para posteriormente serem despejados no armazenamento como TXGs perfeitamente normais (grupos de transações, grupos de transações).

Em operação normal, o ZIL é gravado e nunca mais é lido. Quando, após alguns instantes, as gravações do ZIL são fixadas no armazenamento principal no TXG comum da RAM, elas são desconectadas do ZIL. A única coisa quando algo é lido do ZIL é ao importar o pool.

Se o ZFS travar - o sistema operacional travar ou a falta de energia - quando houver dados no ZIL, esses dados serão lidos durante a próxima importação de pool (por exemplo, quando o sistema de emergência reiniciar). Tudo o que está no ZIL será lido, combinado em grupos TXG, confirmado no armazenamento principal e, em seguida, desconectado do ZIL durante o processo de importação.

Uma das classes auxiliares do vdev é chamada LOG ou SLOG, o dispositivo LOG secundário. Ele tem uma tarefa - fornecer ao pool um dispositivo vdev separado e, de preferência, muito mais rápido, com resistência de gravação muito alta para armazenar o ZIL, em vez de armazenar o ZIL no armazenamento principal do vdev. O próprio ZIL se comporta da mesma maneira, independentemente do local de armazenamento, mas se o vdev com LOG tiver um desempenho de gravação muito alto, as gravações síncronas serão mais rápidas.

Adicionar vdev com LOG ao pool não pode melhorar o desempenho de gravação assíncrona - mesmo se você forçar todas as gravações no ZIL usando zfs set sync=always, elas ainda estarão vinculadas ao repositório principal no TXG da mesma maneira e no mesmo ritmo que sem um log. A única melhoria direta no desempenho é o atraso na gravação síncrona (uma vez que uma velocidade mais alta do log acelera as operações sync).

No entanto, em um ambiente que já exige um grande número de gravações síncronas, o vdev LOG pode indiretamente acelerar gravações assíncronas e leituras não armazenadas em cache. Carregar registros ZIL em um vdev LOG separado significa menos concorrência por IOPS no armazenamento primário, o que, em certa medida, melhora o desempenho de todas as operações de leitura e gravação.

Instantâneos

O mecanismo de cópia de gravação também é uma base essencial para snapshots atômicos do ZFS e replicação assíncrona incremental. O sistema de arquivos ativo possui uma árvore de ponteiros que marca todos os registros com dados atuais - quando você tira um instantâneo, basta fazer uma cópia dessa árvore de ponteiros.

Quando um registro é substituído no sistema de arquivos ativo, o ZFS primeiro grava a nova versão do bloco no espaço não utilizado. Em seguida, desanexa a versão antiga do bloco do sistema de arquivos atual. Mas se algum instantâneo se referir ao bloco antigo, ele permanecerá inalterado. O bloco antigo não será realmente restaurado como espaço livre até que todas as capturas instantâneas vinculadas a esse bloco sejam destruídas!

Replicação

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

Depois de entender como os instantâneos funcionam, é fácil entender a essência da replicação. Como um instantâneo é apenas uma árvore de ponteiros para registros, segue-se que, se fizermos um zfs sendinstantâneo, enviaremos essa árvore e todos os registros associados a ela. Quando passamos este zfs sendem zfs receiveque o objeto alvo, ele escreve ambos o conteúdo real do bloco e da árvore de ponteiros que fazem referência os blocos para o conjunto de dados de destino.

Tudo se torna ainda mais interessante no segundo zfs send. Agora, temos dois sistemas, cada um dos quais contém poolname/datasetname@1, e você tira um novo instantâneo poolname/datasetname@2. Portanto, no pool de origem você possui datasetname@1e datasetname@2, e no pool de destino até agora, apenas o primeiro instantâneo datasetname@1.

Como temos um instantâneo comum entre a origem e o destinodatasetname@1, podemos fazer incremental zfs send em cima disso. Quando dizemos ao sistema zfs send -i poolname/datasetname@1 poolname/datasetname@2, ele compara duas árvores indicadoras. Qualquer ponteiro que exista apenas em @2, obviamente, se refere a novos blocos - portanto, precisamos do conteúdo desses blocos.

Em um sistema remoto, o processamento incremental é sendigualmente simples. Primeiro, registramos todas as novas entradas incluídas no fluxo sende adicionamos ponteiros a esses blocos. Voila, em nosso @2novo sistema!

A replicação incremental assíncrona do ZFS é uma grande melhoria em relação aos métodos anteriores não instantâneos, como o rsync. Nos dois casos, apenas os dados alterados são transmitidos - mas o rsync deve primeiro lerdo disco todos os dados de ambos os lados para verificar a quantidade e compará-la. Por outro lado, a replicação do ZFS lê apenas árvores de ponteiro - e todos os blocos que não são representados no instantâneo geral.

Compactação em linha

O mecanismo de cópia na gravação também simplifica o sistema de compactação embutido. Em um sistema de arquivos tradicional, a compactação é problemática - a versão antiga e a nova versão dos dados alterados estão no mesmo espaço.

Se você considerar um dado no meio de um arquivo que inicia sua vida útil como um megabyte de zeros de 0x00000000 e assim por diante - é muito fácil compactá-lo para um setor do disco. Mas o que acontece se substituirmos esse megabyte de zeros por um megabyte de dados incompressíveis, como JPEG ou ruído pseudo-aleatório? De repente, esse megabyte de dados exigirá não um, mas 256 setores de 4 KiB e, nesse local do disco, apenas um setor será reservado.

O ZFS não tem esse problema, pois os registros alterados são sempre gravados no espaço não utilizado - o bloco original ocupa apenas um setor de 4 KiB e um novo registro leva 256, mas isso não é um problema - um fragmento alterado recentemente do "meio" do arquivo seria gravado no espaço não utilizado independentemente de seu tamanho ter sido alterado ou não, portanto, para o ZFS, essa é uma situação normal.

A compactação ZFS integrada é desativada por padrão e o sistema oferece algoritmos de plug-in - agora entre eles estão LZ4, gzip (1-9), LZJB e ZLE.

O LZ4 é um algoritmo de streaming que oferece ganhos de compactação e descompactação e desempenho extremamente rápidos para a maioria dos casos de uso - mesmo em CPUs bastante lentas.
GZIP — , Unix-. 1-9, CPU 9. ( ) , c CPU — , .
LZJB — ZFS. , LZ4 .
ZLE - codificação de nível zero, codificação de nível zero. Ele não toca nos dados normais, mas comprime grandes seqüências de zeros. Útil para conjuntos de dados completamente incompressíveis (por exemplo, JPEG, MP4 ou outros formatos já compactados), pois ignora dados incompressíveis, mas compacta o espaço não utilizado nos registros resultantes.

Recomendamos a compactação LZ4 para quase todos os casos de uso; A penalidade de desempenho por encontrar dados incompressíveis é muito pequena e o ganho de desempenho para dados típicos é significativo. Copiar uma imagem de máquina virtual para uma nova instalação do sistema operacional Windows (SO recém-instalado, sem dados ainda) compression=lz4passou 27% mais rápido do que com compression=none, neste teste de 2015 .

ARC - cache de substituição adaptável

O ZFS é o único sistema de arquivos moderno conhecido por nós que usa seu próprio mecanismo de cache de leitura e não depende do cache da página do sistema operacional para armazenar cópias de blocos de leitura recentes na RAM.

Embora seu próprio cache não tenha problemas, o ZFS não pode responder a novas solicitações de alocação de memória tão rápido quanto o kernel, portanto, uma nova chamada de malloc()alocação de memória poderá falhar se precisar de RAM atualmente ocupada pelo ARC. Mas há boas razões para usar seu próprio cache, pelo menos por enquanto.

Todos os sistemas operacionais modernos bem conhecidos, incluindo MacOS, Windows, Linux e BSD, usam o algoritmo LRU (Menos Utilizados Recentemente) para implementar o cache da página. Este é um algoritmo primitivo que eleva o bloco em cache "até a fila" após cada leitura e empurra os blocos "em espera" conforme necessário para adicionar novas falhas de cache (blocos que deveriam ter sido lidos a partir do disco, não do cache).

Normalmente, o algoritmo funciona bem, mas em sistemas com grandes conjuntos de dados em funcionamento, o LRU leva facilmente a surtos - eliminando os blocos frequentemente necessários para abrir espaço para blocos que nunca serão lidos no cache novamente.

ARCO - um algoritmo muito menos ingênuo, que pode ser considerado como um cache "ponderado". Após cada leitura do bloco em cache, ele se torna um pouco "mais pesado" e fica mais difícil sair do grupo - e mesmo depois de sair do bloco, o bloco é rastreado por um determinado período de tempo. Um bloco que foi extraído, mas precisa ser lido novamente no cache, também se tornará "mais pesado".

O resultado final de tudo isso é um cache com uma taxa de acerto muito maior - a proporção entre acertos no cache (lidos no cache) e erros (lidos no disco). Essa é uma estatística extremamente importante - não apenas o cache atinge ordens de serviço de magnitude mais rapidamente, mas também pode ser atendido mais rapidamente, porque quanto mais cliques em cache, menos solicitações de disco simultâneas e menos atraso para as falhas restantes que devem ser atendidas. dirigir.

Conclusão

Depois de estudar a semântica básica do ZFS - como a cópia funciona durante a gravação, bem como os relacionamentos entre pools de armazenamento, dispositivos virtuais, blocos, setores e arquivos - estamos prontos para discutir o desempenho real com números reais.

Na próxima parte, veremos o desempenho real de pools com vdev e RAIDz espelhados, em comparação entre si e em comparação com as topologias tradicionais de RAID do kernel Linux, que examinamos anteriormente .

Inicialmente, queríamos considerar apenas o básico - as topologias do ZFS - mas depois disso estaremos prontos para falar sobre o ajuste e ajuste mais avançados do ZFS, incluindo o uso de tipos de vdev auxiliares como L2ARC, SLOG e alocação especial.

Noções básicas do ZFS: armazenamento e desempenho