{"id":83582,"date":"2020-06-01T19:42:21","date_gmt":"2020-06-01T17:42:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/osnovy-zfs-sistema-hraneniya-i-proizvoditelnost"},"modified":"2020-06-01T19:42:21","modified_gmt":"2020-06-01T17:42:21","slug":"osnovy-zfs-sistema-hraneniya-i-proizvoditelnost","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/osnovy-zfs-sistema-hraneniya-i-proizvoditelnost","title":{"rendered":"Fundamentos do ZFS: sistema de armazenamento e desempenho","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Fundamentos
\n
\nNesta primavera, j\u00e1 discutimos alguns t\u00f3picos de introdu\u00e7\u00e3o, como como verificar a velocidade dos seus discos<\/a><\/noindex> e o que \u00e9 RAID<\/a><\/noindex>. No segundo, at\u00e9 prometemos continuar a explorar o desempenho de v\u00e1rias topologias de m\u00faltiplos discos no ZFS. Esta \u00e9 uma sistema de arquivos de pr\u00f3xima gera\u00e7\u00e3o que est\u00e1 sendo implementado em todos os lugares, desde Apple<\/a><\/noindex> at\u00e9 Ubuntu<\/a><\/noindex>.
\n<\/a><\/noindex>
\nBem, hoje \u00e9 o dia mais apropriado para conhecer o ZFS, leitores curiosos. Apenas saibam que, segundo a estimativa modesta do desenvolvedor do OpenZFS, Matt Arenson, \"isso \u00e9 realmente complicado\".<\/p>\n

Mas antes de chegarmos aos n\u00fameros \u2014 e eles vir\u00e3o, prometo \u2014 sobre todas as op\u00e7\u00f5es de configura\u00e7\u00e3o de oito discos do ZFS, precisamos falar sobre como<\/i> o ZFS armazena dados no disco.<\/p>\n

Zpool, vdev e device<\/h1>\n

\n\"Fundamentos
\nEste diagrama de pool completo inclui tr\u00eas vdevs auxiliares, um de cada classe, e quatro para RAIDz2<\/i><\/p>\n

\"Fundamentos
\nNormalmente, n\u00e3o h\u00e1 raz\u00e3o para criar um pool de tipos e tamanhos de vdev incompat\u00edveis \u2014 mas se voc\u00ea quiser, nada impede que voc\u00ea fa\u00e7a isso<\/i><\/p>\n

Para realmente entender o sistema de arquivos ZFS, \u00e9 necess\u00e1rio examinar cuidadosamente sua estrutura real. Em primeiro lugar, o ZFS combina os n\u00edveis tradicionais de gerenciamento de volumes e sistemas de arquivos. Em segundo lugar, utiliza um mecanismo transacional de c\u00f3pia na grava\u00e7\u00e3o. Essas caracter\u00edsticas significam que o sistema \u00e9 estruturalmente muito diferente dos sistemas de arquivos e matrizes RAID comuns. O primeiro conjunto de blocos de constru\u00e7\u00e3o fundamentais para entender: \u00e9 o pool de armazenamento (zpool), dispositivo virtual (vdev) e dispositivo real (device).<\/p>\n

zpool<\/h3>\n

\nO pool de armazenamento zpool \u00e9 a estrutura mais alta do ZFS. Cada pool cont\u00e9m um ou mais dispositivos virtuais. Por sua vez, cada um deles cont\u00e9m um ou mais dispositivos reais (device). Os pools virtuais s\u00e3o blocos aut\u00f4nomos. Um computador f\u00edsico pode conter dois ou mais pools separados, mas cada um \u00e9 completamente independente dos outros. Os pools n\u00e3o podem compartilhar dispositivos virtuais.<\/p>\n

A redund\u00e2ncia do ZFS est\u00e1 no n\u00edvel dos dispositivos virtuais, e n\u00e3o no n\u00edvel dos pools. No n\u00edvel dos pools, n\u00e3o h\u00e1 absolutamente nenhuma redund\u00e2ncia \u2014 se algum armazenamento vdev ou vdev especial for perdido, todo o pool ser\u00e1 perdido junto.<\/p>\n

Os modernos pools de armazenamento podem sobreviver \u00e0 perda do cache ou do log do dispositivo virtual \u2013 embora possam perder uma pequena quantidade de dados sujos se o log do vdev for perdido durante uma queda de energia ou falha do sistema.<\/p>\n

H\u00e1 um equ\u00edvoco comum de que as \u00abfaixas de dados\u00bb (stripes) do ZFS s\u00e3o gravadas por todo o pool. Isso \u00e9 incorreto. Zpool n\u00e3o \u00e9 um RAID0 divertido, \u00e9 mais um divertido JBOD<\/a><\/noindex> com um complexo mecanismo vari\u00e1vel de distribui\u00e7\u00e3o.<\/p>\n

Em sua maior parte, as grava\u00e7\u00f5es s\u00e3o distribu\u00eddas entre os dispositivos virtuais dispon\u00edveis de acordo com o espa\u00e7o livre dispon\u00edvel, de modo que, teoricamente, todos eles ser\u00e3o preenchidos simultaneamente. Nas vers\u00f5es mais recentes do ZFS, o uso atual (utiliza\u00e7\u00e3o) do vdev \u00e9 considerado \u2013 se um dispositivo virtual estiver significativamente mais carregado que outro (por exemplo, devido \u00e0 carga de leitura), ele ser\u00e1 temporariamente ignorado para grava\u00e7\u00e3o, apesar de ter a maior taxa de espa\u00e7o livre.<\/p>\n

O mecanismo de determina\u00e7\u00e3o de utiliza\u00e7\u00e3o, embutido nos modernos m\u00e9todos de distribui\u00e7\u00e3o de gravuras do ZFS, pode reduzir a lat\u00eancia e aumentar a largura de banda durante per\u00edodos de carga incomumente alta \u2013 mas isso n\u00e3o d\u00e1 liberdade total<\/i> para o involunt\u00e1rio agrupamento de HDDs lentos e SSDs r\u00e1pidos em um \u00fanico pool. Um pool desigual ainda funcionar\u00e1 na velocidade do dispositivo mais lento, ou seja, como se fosse composto inteiramente por esses dispositivos.<\/p>\n

vdev<\/h3>\n

\nCada pool de armazenamento consiste em um ou mais dispositivos virtuais (virtual device, vdev). Por sua vez, cada vdev inclui um ou mais dispositivos reais. A maioria dos dispositivos virtuais \u00e9 usada para armazenamento simples de dados, mas existem v\u00e1rias classes auxiliares de vdev, incluindo CACHE, LOG e SPECIAL. Cada um desses tipos de vdev pode ter uma das cinco topologias: dispositivo \u00fanico (single-device), RAIDz1, RAIDz2, RAIDz3 ou espelho (mirror).<\/p>\n

RAIDz1, RAIDz2 e RAIDz3 s\u00e3o tipos especiais do que os antigos chamariam de RAID de paridade dupla (diagonal). O 1, 2 e 3 referem-se ao n\u00famero de blocos de paridade alocados para cada stripe de dados. Em vez de discos separados para fornecer paridade, os dispositivos RAIDz distribuem essa paridade de maneira semi-uniforme entre os discos. Um conjunto RAIDz pode perder tantos discos quantos forem seus blocos de paridade; se perder mais um, ele falhar\u00e1 e levar\u00e1 consigo o pool de armazenamento.<\/p>\n

Em dispositivos virtuais espelhados (mirror vdev), cada bloco \u00e9 armazenado em cada dispositivo no vdev. Embora os espelhos duplos (two-wide) sejam os mais comuns, um espelho pode ter qualquer n\u00famero arbitr\u00e1rio de dispositivos \u2014 em grandes instala\u00e7\u00f5es, para melhorar o desempenho de leitura e a resist\u00eancia a falhas, frequentemente utilizam-se espelhos triplos. Um espelho vdev pode sobreviver a qualquer falha, desde que pelo menos um dispositivo no vdev continue funcionando.<\/p>\n

Os vdevs \u00fanicos s\u00e3o inerentemente perigosos. Um dispositivo virtual desse tipo n\u00e3o sobreviver\u00e1 a nenhuma falha \u2014 e se usado como armazenamento ou vdev especial, sua falha resultar\u00e1 na destrui\u00e7\u00e3o de todo o pool. Tenha muito, muito cuidado aqui.<\/p>\n

Os dispositivos virtuais CACHE, LOG e SPECIAL podem ser criados em qualquer uma das topologias acima mencionadas \u2014 mas lembre-se que a perda de um dispositivo virtual SPECIAL significa a perda do pool, portanto, uma topologia redundante \u00e9 altamente recomendada.<\/p>\n

dispositivo<\/h3>\n

\nTalvez este seja o termo mais f\u00e1cil de entender em ZFS \u2014 \u00e9 literalmente um dispositivo de bloco de acesso aleat\u00f3rio. Lembre-se de que os dispositivos virtuais s\u00e3o compostos de dispositivos separados e o pool \u00e9 feito de dispositivos virtuais.<\/p>\n

Discos \u2014 magn\u00e9ticos ou s\u00f3lidos \u2014 s\u00e3o os dispositivos de bloco mais comuns usados como blocos de constru\u00e7\u00e3o de vdev. No entanto, qualquer dispositivo com um descriptor em \/dev servir\u00e1 \u2014 assim, conjuntos RAID de hardware inteiros podem ser usados como dispositivos separados.<\/p>\n

Um arquivo raw simples \u00e9 um dos dispositivos de bloco alternativos mais importantes que podem ser usados para construir um vdev. Pools de teste de arquivos esparsos<\/a><\/noindex>\u00a0\u2014 s\u00e3o uma maneira muito pr\u00e1tica de testar comandos de pool e ver quanto espa\u00e7o est\u00e1 dispon\u00edvel em um pool ou dispositivo virtual daquela topologia.<\/p>\n

\"Fundamentos
\nVoc\u00ea pode criar um pool de teste com arquivos esparsos em apenas alguns segundos \u2014 mas n\u00e3o se esque\u00e7a de remover todo o pool e seus componentes depois.<\/i> <\/p>\n

Vamos supor que voc\u00ea deseja montar um servidor com oito discos e planeja usar discos de 10 TB (~9300 GiB) \u2014 mas n\u00e3o tem certeza de qual topologia atende melhor \u00e0s suas necessidades. No exemplo acima, estamos construindo um pool de teste com arquivos esparsos em quest\u00e3o de segundos \u2014 e agora sabemos que um vdev RAIDz2 de oito discos de 10 TB fornece 50 TiB de capacidade \u00fatil.<\/p>\n

Outro tipo especial de dispositivos \u00e9 o SPARE (sobressalente). Dispositivos hot-swappable, ao contr\u00e1rio dos dispositivos normais, pertencem a todo o pool e n\u00e3o a um \u00fanico dispositivo virtual. Se algum vdev no pool falhar, e o dispositivo sobressalente estiver conectado ao pool e dispon\u00edvel, ele ser\u00e1 automaticamente alocado ao vdev afetado.<\/p>\n

Ap\u00f3s a aloca\u00e7\u00e3o ao vdev afetado, o dispositivo sobressalente come\u00e7a a receber c\u00f3pias ou reconstru\u00e7\u00f5es dos dados que deveriam estar no dispositivo ausente. Em RAID tradicional, isso \u00e9 chamado de reconstru\u00e7\u00e3o, enquanto no ZFS isso \u00e9 denominado \"restaura\u00e7\u00e3o de redund\u00e2ncia\" (resilvering).<\/p>\n

\u00c9 importante notar que dispositivos sobressalentes n\u00e3o substituem permanentemente dispositivos com falha. Esta \u00e9 apenas uma substitui\u00e7\u00e3o tempor\u00e1ria para reduzir o tempo durante o qual o vdev apresenta degrada\u00e7\u00e3o. Assim que o administrador substituir o dispositivo com falha do vdev, ocorre a restaura\u00e7\u00e3o de redund\u00e2ncia para este dispositivo permanente, enquanto o SPARE se desconecta do vdev e volta a ser um dispositivo sobressalente para todo o pool.<\/p>\n

Conjuntos de dados, blocos e setores<\/h1>\n

\nO pr\u00f3ximo conjunto de blocos de constru\u00e7\u00e3o que precisamos entender em nossa jornada pelo ZFS refere-se n\u00e3o tanto ao hardware, mas a como os pr\u00f3prios dados s\u00e3o organizados e armazenados. Aqui, estamos pulando alguns n\u00edveis \u2014 como o metaslab \u2014 para n\u00e3o sobrecarregar os detalhes, mantendo a compreens\u00e3o da estrutura geral.<\/p>\n

Conjunto de dados (dataset)<\/h3>\n

\n\"Fundamentos
\nQuando criamos um conjunto de dados pela primeira vez, ele mostra todo o espa\u00e7o dispon\u00edvel do pool. Em seguida, estabelecemos uma cota \u2014 e mudamos o ponto de montagem. \u00c9 m\u00e1gica!<\/i> <\/p>\n

\"Fundamentos
\nZvol \u00e9 em grande parte apenas um conjunto de dados livre de sua camada de sistema de arquivos, que substitu\u00edmos aqui por um sistema de arquivos ext4 totalmente normal.<\/i> <\/p>\n

O conjunto de dados ZFS \u00e9 aproximadamente an\u00e1logo a um sistema de arquivos montado padr\u00e3o. Assim como um sistema de arquivos comum, \u00e0 primeira vista, ele pode parecer \"apenas mais uma pasta\". Mas, assim como nos sistemas de arquivos comuns, cada conjunto de dados ZFS possui seu pr\u00f3prio conjunto de propriedades b\u00e1sicas.<\/p>\n

Em primeiro lugar, um conjunto de dados pode ter uma cota atribu\u00edda. Se voc\u00ea definir zfs set quota=100G poolname\/datasetname<\/code>, voc\u00ea n\u00e3o conseguir\u00e1 gravar na pasta montada \/poolname\/datasetname<\/code> mais do que 100 GiB.<\/p>\n

Notou a presen\u00e7a \u2014 e a aus\u00eancia \u2014 de barras no in\u00edcio de cada linha? Cada conjunto de dados tem seu lugar tanto na hierarquia ZFS quanto na hierarquia de montagem do sistema. Na hierarquia ZFS n\u00e3o h\u00e1 uma barra inicial \u2014 voc\u00ea come\u00e7a com o nome do pool e, em seguida, o caminho de um conjunto de dados para outro. Por exemplo, pool\/parent\/child<\/code> para um conjunto de dados chamado child<\/code> sob o conjunto de dados pai parent<\/code> em um pool com o nome criativo pool<\/code>.<\/p>\n

Por padr\u00e3o, o ponto de montagem do conjunto de dados ser\u00e1 equivalente ao seu nome na hierarquia ZFS, com uma barra no in\u00edcio \u2014 o pool com o nome pool<\/code> ser\u00e1 montado como \/pool<\/code>, o conjunto de dados parent<\/code> ser\u00e1 montado em \/pool\/parent<\/code>, e o conjunto de dados filho child<\/code> ser\u00e1 montado em \/pool\/parent\/child<\/code>. No entanto, o ponto de montagem do sistema para o conjunto de dados pode ser alterado.<\/p>\n

Se especificarmos zfs set mountpoint=\/lol pool\/parent\/child<\/code>, ent\u00e3o o conjunto de dados pool\/parent\/child<\/code> ser\u00e1 montado no sistema como \/lol<\/code>.<\/p>\n

Al\u00e9m dos conjuntos de dados, devemos mencionar os volumes (zvols). O volume \u00e9 aproximadamente an\u00e1logo a um conjunto de dados, exceto que ele n\u00e3o possui um sistema de arquivos real \u2014 \u00e9 apenas um dispositivo de bloco. Voc\u00ea pode, por exemplo, criar zvol<\/code> com o nome mypool\/myzvol<\/code>, ent\u00e3o format\u00e1-lo com um sistema de arquivos ext4 e, em seguida, montar esse sistema de arquivos \u2014 agora voc\u00ea tem um sistema de arquivos ext4, mas com suporte a todos os recursos de seguran\u00e7a do ZFS! Isso pode parecer estranho em um \u00fanico computador, mas faz muito mais sentido como backend ao exportar um dispositivo iSCSI.<\/p>\n

Blocos<\/h3>\n

\n\"Fundamentos
\nUm arquivo \u00e9 representado por um ou mais blocos. Cada bloco \u00e9 armazenado em um \u00fanico dispositivo virtual. O tamanho do bloco geralmente \u00e9 igual ao par\u00e2metro recordsize<\/b>, mas pode ser reduzido para 2^ashift<\/b>, se contiver metadados ou um arquivo pequeno.<\/i><\/p>\n

\"Fundamentos
\nN\u00f3s realmente, realmente<\/b> n\u00e3o estamos brincando sobre o enorme impacto no desempenho, se definir um ashift muito pequeno.<\/i><\/p>\n

No pool ZFS, todos os dados, incluindo metadados, s\u00e3o armazenados em blocos. O tamanho m\u00e1ximo do bloco para cada conjunto de dados \u00e9 determinado pela propriedade recordsize<\/code> (tamanho do registro). O tamanho do registro pode variar, mas isso n\u00e3o alterar\u00e1 o tamanho ou a localiza\u00e7\u00e3o de quaisquer blocos que j\u00e1 tenham sido gravados no conjunto de dados - ele se aplica apenas a novos blocos \u00e0 medida que s\u00e3o gravados.<\/p>\n

Se n\u00e3o for especificado de outra forma, o tamanho do registro atual padr\u00e3o \u00e9 de 128 KiB. \u00c9 uma esp\u00e9cie de compromisso razo\u00e1vel, onde o desempenho n\u00e3o ser\u00e1 ideal, mas tamb\u00e9m n\u00e3o ser\u00e1 horr\u00edvel na maioria dos casos. Tamanho do registro<\/code> pode ser ajustado para qualquer valor de 4K a 1M (com configura\u00e7\u00f5es adicionais recordsize<\/code> pode ser definido ainda maior, mas isso raramente \u00e9 uma boa ideia).<\/p>\n

Qualquer bloco se refere a dados de um \u00fanico arquivo - voc\u00ea n\u00e3o pode colocar dois arquivos diferentes em um bloco. Cada arquivo consiste de um ou mais blocos, dependendo do tamanho. Se o tamanho do arquivo for menor que o tamanho do registro, ele ser\u00e1 armazenado em um bloco menor - por exemplo, um bloco com um arquivo de 2 KiB ocupar\u00e1 apenas um setor de 4 KiB no disco.<\/p>\n

Os volumes zvol n\u00e3o t\u00eam a propriedade recordsize<\/code>\u00a0\u2014 em vez disso, eles t\u00eam uma propriedade equivalente volblocksize<\/code>.<\/p>\n

Setores<\/h3>\n

\nO \u00faltimo e mais b\u00e1sico bloco de constru\u00e7\u00e3o \u00e9 o setor. Esta \u00e9 a menor unidade f\u00edsica que pode ser gravada ou lida do dispositivo base. Durante v\u00e1rias d\u00e9cadas, a maioria dos discos usou setores de 512 bytes. Recentemente, a maioria dos discos est\u00e1 configurada para setores de 4 KiB, e alguns - especialmente SSDs - t\u00eam setores de 8 KiB ou at\u00e9 mais.<\/p>\n

No sistema ZFS, h\u00e1 uma propriedade que permite definir manualmente o tamanho do setor. Esta propriedade ashift<\/code>. \u00c9 um pouco confuso que ashift seja uma pot\u00eancia de dois. Por exemplo, ashift=9<\/code> significa um tamanho de setor de 2^9, ou 512 bytes.<\/p>\n

O ZFS solicita ao sistema operacional informa\u00e7\u00f5es detalhadas sobre cada dispositivo de bloco quando \u00e9 adicionado a um novo vdev e teoricamente ajusta automaticamente o ashift corretamente com base nessas informa\u00e7\u00f5es. Infelizmente, muitos discos mentem sobre o tamanho de seu setor para manter a compatibilidade com o Windows XP (que era incapaz de entender discos com tamanhos de setor diferentes).<\/p>\n

Isso significa que \u00e9 fortemente recomendado que o administrador do ZFS conhe\u00e7a o tamanho real do setor de seus dispositivos e configure manualmente ashift<\/code>. Se um ashift muito pequeno for configurado, o n\u00famero de opera\u00e7\u00f5es de leitura\/grava\u00e7\u00e3o aumenta astronomicamente. Por exemplo, gravar \"setores\" de 512 bytes em um setor real de 4 KiB significa que \u00e9 necess\u00e1rio gravar o primeiro \"setor\", depois ler o setor de 4 KiB, modific\u00e1-lo com o segundo \"setor\" de 512 bytes, grav\u00e1-lo de volta em um novo setor de 4 KiB e assim por diante para cada grava\u00e7\u00e3o.<\/p>\n

No mundo real, essa penaliza\u00e7\u00e3o atinge os SSDs Samsung EVO, para os quais deve ser aplicada ashift=13<\/code>, mas esses SSDs mentem sobre seu tamanho de setor e, portanto, por padr\u00e3o \u00e9 definido ashift=9<\/code>. Se um administrador de sistema experiente n\u00e3o alterar essa configura\u00e7\u00e3o, esse SSD funcionar\u00e1 mais devagar<\/i> do que um HDD magn\u00e9tico comum.<\/p>\n

Em compara\u00e7\u00e3o, para um tamanho muito grande ashift<\/code> praticamente n\u00e3o h\u00e1 penaliza\u00e7\u00e3o. N\u00e3o h\u00e1 redu\u00e7\u00e3o real de desempenho, e o aumento do espa\u00e7o n\u00e3o utilizado \u00e9 infinitesimal (ou igual a zero com a compress\u00e3o ativada). Portanto, recomendamos fortemente que at\u00e9 mesmo os discos que realmente utilizam setores de 512 bytes configurem ashift=12<\/code> ou at\u00e9 mesmo ashift=13<\/code>, para ter uma vis\u00e3o segura do futuro.<\/p>\n

A propriedade ashift<\/code> \u00e9 configurado para cada dispositivo virtual vdev, e n\u00e3o para o pool<\/i>, como muitos pensam erroneamente \u2014 e n\u00e3o \u00e9 alterado ap\u00f3s a configura\u00e7\u00e3o. Se voc\u00ea acidentalmente desviar ashift<\/code> ao adicionar um novo vdev ao pool, voc\u00ea contaminou irreversivelmente esse pool com um dispositivo de baixo desempenho e, em geral, n\u00e3o h\u00e1 outra sa\u00edda a n\u00e3o ser destruir o pool e come\u00e7ar tudo de novo. Mesmo a remo\u00e7\u00e3o do vdev n\u00e3o salvar\u00e1 a configura\u00e7\u00e3o desvirtuada. ashift<\/code>!<\/p>\n

O mecanismo de c\u00f3pia ao escrever<\/h3>\n

\n\"Fundamentos
\nSe um sistema de arquivos normal precisar reescrever dados \u2014 ele altera cada bloco onde est\u00e1 localizado.<\/i><\/p>\n

\"Fundamentos
\nO sistema de arquivos com c\u00f3pia sob demanda grava uma nova vers\u00e3o do bloco e, em seguida, desbloqueia a vers\u00e3o antiga.<\/i><\/p>\n

\"Fundamentos
\nDe maneira abstrata, se ignorarmos a localiza\u00e7\u00e3o f\u00edsica real dos blocos, nossa \"cometa de dados\" se simplifica para um \"verme de dados\" que se move da esquerda para a direita no mapa do espa\u00e7o dispon\u00edvel.<\/i><\/p>\n

\"Fundamentos
\nAgora podemos ter uma boa compreens\u00e3o de como funcionam os snapshots de c\u00f3pia sob demanda \u2014 cada bloco pode pertencer a v\u00e1rios snapshots e ser\u00e1 mantido at\u00e9 que todos os snapshots associados sejam destru\u00eddos.<\/i><\/p>\n

O mecanismo de c\u00f3pia sob demanda (Copy on Write, CoW) \u00e9 a base fundamental do que torna o ZFS um sistema t\u00e3o impressionante. O conceito principal \u00e9 simples \u2014 se voc\u00ea pedir a um sistema de arquivos tradicional para alterar um arquivo, ele far\u00e1 exatamente o que voc\u00ea pediu. Se voc\u00ea pedir a um sistema de arquivos com c\u00f3pia sob demanda para fazer o mesmo, ele dir\u00e1 \"ok\" \u2014 mas te enganar\u00e1.<\/p>\n

Em vez disso, o sistema de arquivos com c\u00f3pia sob demanda grava uma nova vers\u00e3o do bloco alterado e, em seguida, atualiza os metadados do arquivo para quebrar a conex\u00e3o com o bloco antigo e vincul\u00e1-lo ao novo bloco que voc\u00ea acabou de gravar.<\/p>\n

Desvincular o bloco antigo e vincular o novo \u00e9 feito em uma \u00fanica opera\u00e7\u00e3o, portanto, n\u00e3o pode ser interrompido \u2014 se voc\u00ea cortar a energia ap\u00f3s isso ocorrer, voc\u00ea ter\u00e1 uma nova vers\u00e3o do arquivo, e se voc\u00ea cortar a energia antes, ter\u00e1 a vers\u00e3o antiga. Em qualquer dos casos, n\u00e3o haver\u00e1 conflitos no sistema de arquivos.<\/p>\n

A c\u00f3pia sob demanda no ZFS ocorre n\u00e3o apenas no n\u00edvel do sistema de arquivos, mas tamb\u00e9m no n\u00edvel de gerenciamento de discos. Isso significa que o ZFS n\u00e3o est\u00e1 sujeito ao problema de grava\u00e7\u00e3o (buraco no RAID<\/a><\/noindex>) \u2014 um fen\u00f4meno onde a faixa foi apenas parcialmente gravada antes da falha do sistema, resultando em corrup\u00e7\u00e3o do array ap\u00f3s a reinicializa\u00e7\u00e3o. Aqui, a faixa \u00e9 gravada de forma at\u00f4mica, o vdev \u00e9 sempre consistente, e Bob \u00e9 seu tio<\/a><\/noindex>.<\/p>\n

ZIL: log de inten\u00e7\u00f5es do ZFS<\/h3>\n

\n\"Fundamentos
\nO sistema ZFS trata grava\u00e7\u00f5es s\u00edncronas de maneira especial \u2014 ele as armazena temporariamente, mas imediatamente, no ZIL, antes de grav\u00e1-las de forma permanente juntamente com as grava\u00e7\u00f5es ass\u00edncronas.<\/i><\/p>\n

\"Fundamentos
\nNormalmente, os dados gravados no ZIL nunca mais s\u00e3o lidos. Mas isso \u00e9 poss\u00edvel ap\u00f3s uma falha do sistema.<\/i><\/p>\n

\"Fundamentos
\nSLOG, ou dispositivo LOG secund\u00e1rio, \u00e9 simplesmente um vdev especial - e, preferencialmente, muito r\u00e1pido - onde o ZIL pode ser armazenado separadamente do armazenamento principal.<\/i><\/p>\n

\"Fundamentos
\nAp\u00f3s uma falha, todos os dados sujos no ZIL s\u00e3o reproduzidos - neste caso, o ZIL est\u00e1 no SLOG, ent\u00e3o eles s\u00e3o reproduzidos precisamente de l\u00e1.<\/i><\/p>\n

Existem duas categorias principais de opera\u00e7\u00f5es de grava\u00e7\u00e3o - s\u00edncronas (sync) e ass\u00edncronas (async). Para a maioria das cargas de trabalho, a grande maioria das opera\u00e7\u00f5es de grava\u00e7\u00e3o \u00e9 ass\u00edncrona - o sistema de arquivos permite agreg\u00e1-las e emit\u00ed-las em pacotes, reduzindo a fragmenta\u00e7\u00e3o e aumentando significativamente a largura de banda.<\/p>\n

As grava\u00e7\u00f5es s\u00edncronas s\u00e3o uma hist\u00f3ria completamente diferente. Quando um aplicativo solicita uma grava\u00e7\u00e3o s\u00edncrona, ele diz ao sistema de arquivos: \"Voc\u00ea precisa fixar isso na mem\u00f3ria n\u00e3o vol\u00e1til. neste momento.<\/i>, e at\u00e9 l\u00e1 n\u00e3o posso fazer mais nada.\" Por isso, as grava\u00e7\u00f5es s\u00edncronas devem ser imediatamente fixadas no disco - e se isso aumentar a fragmenta\u00e7\u00e3o ou reduzir a largura de banda, que assim seja.<\/p>\n

O ZFS lida com grava\u00e7\u00f5es s\u00edncronas de maneira diferente das sistemas de arquivos tradicionais - em vez de empurr\u00e1-las imediatamente para o armazenamento normal, o ZFS as fixa em uma \u00e1rea de armazenamento especial chamada ZFS Intent Log, ou ZIL. A sacada \u00e9 que essas grava\u00e7\u00f5es tamb\u00e9m<\/i> permanecem na mem\u00f3ria, sendo agregadas juntamente com as solicita\u00e7\u00f5es de grava\u00e7\u00e3o ass\u00edncronas normais, para serem posteriormente descartadas no armazenamento como TXG (grupos de transa\u00e7\u00f5es, Transaction Groups) completamente normais.<\/p>\n

No modo de opera\u00e7\u00e3o normal, o ZIL \u00e9 gravado e nunca mais lido. Quando, ap\u00f3s alguns momentos, as grava\u00e7\u00f5es do ZIL s\u00e3o fixadas no armazenamento principal nos TXGs normais da mem\u00f3ria, elas s\u00e3o desanexadas do ZIL. A \u00fanica vez que algo \u00e9 lido do ZIL \u00e9 durante a importa\u00e7\u00e3o do pool.<\/p>\n

Se ocorrer uma falha no ZFS - falha do sistema operacional ou desligamento de energia - quando h\u00e1 dados no ZIL, esses dados ser\u00e3o lidos durante a pr\u00f3xima importa\u00e7\u00e3o do pool (por exemplo, ao reiniciar um sistema de recupera\u00e7\u00e3o). Tudo que estiver no ZIL ser\u00e1 lido, combinado em grupos TXG, fixado no armazenamento principal e, em seguida, desanexado do ZIL durante o processo de importa\u00e7\u00e3o.<\/p>\n

Uma das classes auxiliares do vdev \u00e9 chamada de LOG ou SLOG, que \u00e9 um dispositivo LOG secund\u00e1rio. Sua \u00fanica fun\u00e7\u00e3o \u00e9 fornecer ao pool um dispositivo vdev separado e, de prefer\u00eancia, muito mais r\u00e1pido, com alta resist\u00eancia \u00e0 grava\u00e7\u00e3o, para armazenar o ZIL, em vez de armazenar o ZIL no armazenamento vdev principal. O ZIL em si se comporta da mesma forma, independentemente do local de armazenamento, mas se um vdev com LOG tem um desempenho de grava\u00e7\u00e3o muito alto, as grava\u00e7\u00f5es s\u00edncronas ocorrer\u00e3o mais rapidamente.<\/p>\n

Adicionar um vdev com LOG ao pool de nenhuma forma pode<\/b> melhorar o desempenho de grava\u00e7\u00e3o ass\u00edncrona \u2014 mesmo que voc\u00ea force todas as grava\u00e7\u00f5es no ZIL com zfs set sync=always<\/code>, elas ainda estar\u00e3o ligadas ao armazenamento principal no TXG da mesma forma e no mesmo ritmo que sem o log. A \u00fanica melhora direta no desempenho \u00e9 a lat\u00eancia de grava\u00e7\u00e3o s\u00edncrona (j\u00e1 que uma velocidade maior do log acelera a execu\u00e7\u00e3o das opera\u00e7\u00f5es sync<\/code>).<\/p>\n

Entretanto, em um ambiente que j\u00e1 requer um grande n\u00famero de grava\u00e7\u00f5es s\u00edncronas, o vdev LOG pode indiretamente acelerar grava\u00e7\u00f5es ass\u00edncronas e leituras n\u00e3o em cache. O descarregamento de grava\u00e7\u00f5es ZIL para um vdev LOG separado significa menos competi\u00e7\u00e3o por IOPS no armazenamento prim\u00e1rio, o que em certa medida melhora o desempenho de todas as opera\u00e7\u00f5es de leitura e grava\u00e7\u00e3o.<\/p>\n

Snapshots<\/h3>\n

\nO mecanismo de c\u00f3pia em grava\u00e7\u00e3o tamb\u00e9m \u00e9 uma base necess\u00e1ria para instant\u00e2neas at\u00f4micas do ZFS e replica\u00e7\u00e3o ass\u00edncrona incremental. Em um sistema de arquivos ativo, existe uma \u00e1rvore de ponteiros que marca todas as grava\u00e7\u00f5es com os dados atuais \u2014 quando voc\u00ea cria um snapshot, est\u00e1 apenas fazendo uma c\u00f3pia dessa \u00e1rvore de ponteiros.<\/p>\n

Quando uma grava\u00e7\u00e3o \u00e9 reescrita em um sistema de arquivos ativo, o ZFS primeiro grava uma nova vers\u00e3o do bloco em um espa\u00e7o n\u00e3o utilizado. Ent\u00e3o, ele desvincula a vers\u00e3o antiga do bloco do sistema de arquivos atual. Mas se algum snapshot fizer refer\u00eancia ao bloco antigo, ele permanece inalterado. O bloco antigo, de fato, n\u00e3o ser\u00e1 recuperado como espa\u00e7o livre at\u00e9 que todos os snapshots que referenciam esse bloco sejam destru\u00eddos!<\/p>\n

Replica\u00e7\u00e3o<\/h3>\n

\n\"Fundamentos
\nMinha biblioteca Steam em 2015 ocupava 158 GiB e inclu\u00eda 126.927 arquivos. Isso \u00e9 bastante pr\u00f3ximo da situa\u00e7\u00e3o ideal para rsync \u2014 a replica\u00e7\u00e3o do ZFS pela rede foi \"apenas\" 750% mais r\u00e1pida.<\/i><\/p>\n

\"Fundamentos
\nNa mesma rede, a replica\u00e7\u00e3o de um arquivo de imagem de m\u00e1quina virtual Windows 7 de 40 gibibytes \u00e9 uma hist\u00f3ria completamente diferente. A replica\u00e7\u00e3o ZFS ocorre 289 vezes mais r\u00e1pida do que o rsync \u2014 ou 'apenas' 161 vezes mais r\u00e1pida, se voc\u00ea souber usar o rsync com a op\u00e7\u00e3o \u2014inplace.<\/i><\/p>\n

\"Fundamentos
\nQuando a imagem da m\u00e1quina virtual \u00e9 escalada, os problemas do rsync tamb\u00e9m escalonam. Um tamanho de 1,9 TiB n\u00e3o \u00e9 t\u00e3o grande para uma imagem de m\u00e1quina virtual moderna \u2014 mas \u00e9 grande o suficiente para que a replica\u00e7\u00e3o ZFS seja 1148 vezes mais r\u00e1pida que o rsync, mesmo com o argumento rsync \u2014inplace.<\/i><\/p>\n

Assim que voc\u00ea entender como funcionam os snapshots, n\u00e3o ser\u00e1 dif\u00edcil captar a ess\u00eancia da replica\u00e7\u00e3o. Como um snapshot \u00e9 apenas uma \u00e1rvore de ponteiros para os registros, isso implica que, ao fazermos zfs send<\/code> de um snapshot, enviamos tanto essa \u00e1rvore quanto todos os registros associados a ela. Quando transferimos isso para zfs send<\/code> em zfs receive<\/code> no objeto de destino, ele grava tanto o conte\u00fado real do bloco quanto a \u00e1rvore de ponteiros que se referem aos blocos no conjunto de dados de destino.<\/p>\n

As coisas ficam ainda mais interessantes na segunda zfs send<\/code>. Agora temos dois sistemas, cada um contendo poolname\/datasetname@1<\/code>, e voc\u00ea tira um novo snapshot poolname\/datasetname@2<\/code>. Portanto, no pool de origem, voc\u00ea tem datasetname@1<\/code> e datasetname@2<\/code>, e no pool de destino, apenas o primeiro snapshot por enquanto. datasetname@1<\/code>.<\/p>\n

Como temos um snapshot compartilhado entre a fonte e o destino datasetname@1<\/code>, podemos fazer incremental<\/i> zfs send<\/code> sobre ele. Quando dizemos ao sistema zfs send -i poolname\/datasetname@1 poolname\/datasetname@2<\/code>, ele compara as duas \u00e1rvores de ponteiros. Qualquer ponteiro que exista apenas em @2<\/code>, obviamente, aponta para novos blocos \u2014 ent\u00e3o precisaremos do conte\u00fado desses blocos.<\/p>\n

No sistema remoto, o processamento incremental send<\/code> \u00e9 igualmente simples. Primeiro, gravamos todos os novos registros inclu\u00eddos no fluxo send<\/code>, e ent\u00e3o adicionamos ponteiros para esses blocos. Voil\u00e0, temos @2<\/code> no novo sistema!<\/p>\n

A replica\u00e7\u00e3o incremental ass\u00edncrona do ZFS \u00e9 uma grande melhoria em rela\u00e7\u00e3o aos m\u00e9todos anteriores que n\u00e3o s\u00e3o baseados em snapshots, como o rsync. Em ambos os casos, apenas os dados alterados s\u00e3o transferidos \u2014 mas o rsync deve primeiro ler<\/i> ler todos os dados de ambos os lados do disco para verificar a soma e compar\u00e1-la. Em contraste, a replica\u00e7\u00e3o ZFS n\u00e3o l\u00ea nada al\u00e9m das \u00e1rvores de ponteiros \u2014 e quaisquer blocos que n\u00e3o estejam representados no snapshot compartilhado.<\/p>\n

Compress\u00e3o embutida<\/h3>\n

\nO mecanismo de c\u00f3pia na grava\u00e7\u00e3o tamb\u00e9m simplifica o sistema de compress\u00e3o embutida. Em sistemas de arquivos tradicionais, a compress\u00e3o \u00e9 problem\u00e1tica \u2014 tanto a vers\u00e3o antiga quanto a nova dos dados alterados ocupam o mesmo espa\u00e7o.<\/p>\n

Se analisarmos um fragmento de dados no meio de um arquivo, que come\u00e7a sua vida como um megabyte de zeros a partir de 0x00000000 e assim por diante \u2014 ele pode ser facilmente compactado para um \u00fanico setor no disco. Mas o que acontece se substitu\u00edmos esse megabyte de zeros por um megabyte de dados n\u00e3o compact\u00e1veis, como JPEG ou ru\u00eddo pseudoaleat\u00f3rio? De repente, esse megabyte de dados exigir\u00e1 n\u00e3o um, mas 256 setores de 4 KiB, e nesse local no disco est\u00e1 reservado apenas um setor.<\/p>\n

O ZFS n\u00e3o tem esse problema, uma vez que as grava\u00e7\u00f5es alteradas s\u00e3o sempre escritas em espa\u00e7o n\u00e3o utilizado \u2014 o bloco original ocupa apenas um setor de 4 KiB, e a nova grava\u00e7\u00e3o ocupar\u00e1 256, mas isso n\u00e3o \u00e9 um problema \u2014 o fragmento recentemente modificado do \"meio\" do arquivo seria gravado em espa\u00e7o n\u00e3o utilizado, independentemente de ter mudado de tamanho ou n\u00e3o, portanto, para o ZFS isso \u00e9 uma situa\u00e7\u00e3o bastante comum.<\/p>\n

A compress\u00e3o embutida do ZFS est\u00e1 desativada por padr\u00e3o, e o sistema oferece algoritmos plug\u00e1veis \u2014 atualmente, entre eles est\u00e3o o LZ4, gzip (1-9), LZJB e ZLE.<\/p>\n

Se o arquivo for grande o suficiente e exigir v\u00e1rios blocos, todas as grava\u00e7\u00f5es com esse arquivo ter\u00e3o um tamanho recordsize<\/code>\u00a0\u2014 incluindo a \u00faltima grava\u00e7\u00e3o, cuja maior parte pode ser espa\u00e7o n\u00e3o utilizado<\/a><\/noindex>.<\/p>\n