ZFS: Conheça o Significado dos Termos Usados

Mais do que um sistema de arquivos, ZFS é fundamentalmente diferente. ZFS combina as funções de sistema de arquivos e gerenciador de volumes, permitindo que novos dispositivos de armazenamento sejam adicionados a um sistema ativo e tendo o novo espaço disponível nos sistemas de arquivos existentes nesse pool de uma só vez. Ao combinar as funções tradicionalmente separadas, o ZFS é capaz de superar as limitações anteriores que impediam o crescimento dos grupos de RAID. Um vdev é um dispositivo de nível superior em um pool e pode ser um disco simples ou uma transformação RAID, como um espelho(mirror) ou matriz RAID-Z. Cada um dos sistemas de arquivos ZFS (chamados dataset ou conjuntos de dados) tem acesso ao espaço livre combinado de todo o pool. Os blocos usados ​​do pool diminuem o espaço disponível para cada sistema de arquivos. Essa abordagem evita a armadilha comum com particionamento extensivo em que o espaço livre se torna fragmentado entre as partições.

TERMO	SIGNIFICADO
Pool	Um pool de armazenamento é o bloco de construção mais básico do ZFS. Um pool consiste em um ou mais vdevs, os dispositivos subjacentes que armazenam os dados. Um pool é então usado para criar um ou mais sistemas de arquivos(datasets) ou dispositivos de bloco (volumes). Esses datasets e volumes compartilham o pool de espaço livre restante. Cada pool é identificado exclusivamente por um nome e um GUID. O número da versão do ZFS no pool determina os recursos disponíveis.
Tipos de vdev	Um pool consiste em um ou mais vdevs, que são um único disco ou um grupo de discos, transformados em RAID. Ao usar muitos vdevs, o ZFS distribui os dados pelos vdevs para aumentar o desempenho e maximizar o espaço utilizável. Todos os vdevs devem ter pelo menos 128 MB de tamanho. Usar um disco inteiro como parte de um pool inicializável é altamente desencorajado, pois isso pode tornar o pool não inicializável. Da mesma forma, você não deve usar um disco inteiro como parte de um espelho ou RAID-Z vdev. Determinar de forma confiável o tamanho de um disco não particionado no momento da inicialização é impossível e não há lugar para inserir o código de inicialização. Vamos ver os tipos de vdevs: # Disco: O tipo vdev mais básico é um dispositivo de bloco padrão. Pode ser um disco inteiro (como /dev/sdb ou /dev/sdc) ou uma partição (/dev/sdb3). No FreeBSD, não há perda de desempenho por usar uma partição em vez do disco inteiro. Isso difere das recomendações feitas pela documentação do Solaris. # Arquivo: Arquivos regulares podem compor pools ZFS, o que é útil para testes e experimentação. Use o caminho completo para o arquivo como o caminho do dispositivo em zpool create. # espelho: Ao criar um espelho(mirror), especifique a palavra-chave espelho seguida pela lista de dispositivos membros para o espelho. Um espelho consiste em dois ou mais dispositivos, gravando todos os dados em todos os dispositivos membros. Um mirror vdev manterá tantos dados quanto seu menor membro. Um mirror vdev pode suportar a falha de todos, exceto um de seus membros, sem perder nenhum dado. Dica: Para atualizar um vdev de disco único para um vdev de espelho a qualquer momento, use zpool attach. # RAID-Z : O ZFS usa RAID-Z, uma variação do RAID-5 padrão que oferece melhor distribuição de paridade e elimina o “buraco de gravação RAID-5” no qual os dados e as informações de paridade tornam-se inconsistentes após uma reinicialização inesperada. O ZFS oferece suporte a três níveis de RAID-Z, que fornecem níveis variados de redundância em troca de níveis decrescentes de armazenamento utilizável. O ZFS usa RAID-Z1 a RAID-Z3 com base no número de dispositivos de paridade na matriz e no número de discos que podem falhar antes que o pool pare de funcionar. Em uma configuração RAID-Z1 com quatro discos, cada um com 1 TB, o armazenamento utilizável é de 3 TB e o pool ainda poderá operar em modo degradado com um disco com falha. Se outro disco ficar off-line antes de substituir e restaurar o disco com falha, todos os dados do pool serão perdidos. Em uma configuração RAID-Z3 com oito discos de 1 TB, o volume fornecerá 5 TB de espaço utilizável e ainda poderá operar com três discos com falha. A Sun™ não recomenda mais de nove discos em um único vdev. Se mais discos compõem a configuração, a recomendação é dividi-los em vdevs separados e distribuir os dados do pool entre eles. Uma configuração de dois vdevs RAID-Z2 consistindo em 8 discos cada criaria algo como uma matriz RAID-60. A capacidade de armazenamento de um grupo RAID-Z é aproximadamente o tamanho do menor disco multiplicado pelo número de discos sem paridade. Quatro discos de 1 TB em RAID-Z1 têm um tamanho efetivo de cerca de 3 TB, e uma matriz de oito discos de 1 TB em RAID-Z3 renderá 5 TB de espaço utilizável. # Spare – o ZFS tem um tipo pseudo-vdev especial para acompanhar os hot spares disponíveis. Observe que os hot spares instalados não são implantados automaticamente; configure-os manualmente para substituir o dispositivo com falha usando o zfs replace. # Log – os dispositivos de log ZFS, também conhecidos como ZFS Intent Log (ZIL) movem o log de intenção dos dispositivos de pool regulares para um dispositivo dedicado, geralmente um SSD. Ter um dispositivo de log dedicado melhora o desempenho de aplicativos com um alto volume de gravações síncronas, como bancos de dados. O espelhamento de dispositivos de log é possível, mas o RAID-Z não é suportado. Se estiver usando muitos dispositivos de log, as gravações terão balanceamento de carga entre eles. # Cache – Adicionar um cache vdev a um pool adicionará o armazenamento do cache ao L2ARC. O espelhamento de dispositivos de cache é impossível. Como um dispositivo de cache armazena apenas novas cópias dos dados existentes, não há risco de perda de dados. L2ARC (Level 2 Adaptive Replacement Cache) é um componente do sistema de armazenamento ZFS usado para melhorar o desempenho de leitura em sistemas de armazenamento de dados. Ele consiste em utilizar dispositivos de armazenamento SSD como uma camada de cache para acelerar o acesso aos dados mais frequentemente acessados.
Transaction Group (TXG) ou Grupos de transações	Grupos de transações são a forma como os grupos do ZFS bloqueiam as alterações e as gravam no pool. Os grupos de transações são a unidade atômica que o ZFS usa para garantir a consistência. O ZFS atribui a cada grupo de transações um identificador consecutivo exclusivo de 64 bits. Pode haver até três grupos de transações ativos por vez, um em cada um destes três estados: * Open – Um novo grupo de transações começa no estado aberto(open) e aceita novas gravações. Há sempre um grupo de transações no estado aberto, mas o grupo de transações pode recusar novas gravações se tiver atingido um limite. Uma vez que o grupo de transações abertas tenha atingido um limite, ou atingido o vfs.zfs.txg.timeout, o grupo de transações avança para o próximo estado. * Quiescing – Um estado curto que permite que quaisquer operações pendentes terminem sem bloquear a criação de um novo grupo de transações abertas. Depois que todas as transações no grupo forem concluídas, o grupo de transações avança para o estado final. * Syncing – ou sincronizando. Grave todos os dados no grupo de transações no armazenamento estável. Esse processo, por sua vez, alterará outros dados, como metadados e mapas espaciais, que o ZFS também gravará no armazenamento estável. O processo de sincronização envolve várias passagens. No primeiro e maior, todos os blocos de dados alterados; em seguida, vêm os metadados, que podem levar várias passagens para serem concluídos. Como a alocação de espaço para os blocos de dados gera novos metadados, o estado de sincronização não pode terminar até que uma passagem seja concluída e não use nenhum novo espaço. O estado de sincronização também é onde as tarefas de sincronização são concluídas. Synctasks são operações administrativas, como criar ou destruir instantâneos e conjuntos de dados que concluem a alteração do uberblock. Depois que o estado de sincronização é concluído, o grupo de transações no estado de encerramento avança para o estado de sincronização. Todas as funções administrativas, como gravação de instantâneo como parte do grupo de transações. O ZFS adiciona uma tarefa de sincronização criada ao grupo de transações abertas e esse grupo avança o mais rápido possível para o estado de sincronização para reduzir a latência dos comandos administrativos.
Adaptive Replacement Cache (ARC) ou Cache de substituição adaptável (ARC)	ZFS usa um cache de substituição adaptável (ARC), em vez de um cache mais tradicional menos usado recentemente (LRU). Um cache LRU é uma lista simples de itens no cache, classificados por quão recentemente o objeto foi usado, adicionando novos itens ao início da lista. Quando o cache está cheio, remover itens do final da lista abre espaço para mais objetos ativos. Um ARC consiste em quatro listas; os objetos usados ​​mais recentemente (MRU) e usados ​​com mais frequência (MFU), além de uma lista fantasma para cada um. Essas listas fantasmas rastreiam objetos despejados para evitar adicioná-los de volta ao cache. Isso aumenta a taxa de ocorrência do cache, evitando objetos com histórico de uso ocasional. Outra vantagem de usar um MRU e um MFU é que a varredura de um sistema de arquivos inteiro removeria todos os dados de um cache MRU ou LRU em favor desse conteúdo recém-acessado. Com o ZFS, há também um MFU que rastreia os objetos usados ​​com mais frequência, e o cache dos blocos acessados ​​com mais frequência permanece.
L2ARC	L2ARC é o segundo nível do sistema de cache ZFS. A RAM armazena o ARC primário. Como a quantidade de RAM disponível costuma ser limitada, o ZFS também pode usar cache vdevs. Os discos de estado sólido (SSDs) são frequentemente usados ​​como esses dispositivos de cache devido à sua maior velocidade e menor latência em comparação com os discos giratórios tradicionais. O L2ARC é totalmente opcional, mas ter um aumentará as velocidades de leitura dos arquivos em cache no SSD, em vez de ter que ler os discos regulares. O L2ARC também pode acelerar a desduplicação porque uma tabela de desduplicação (DDT) que não cabe na RAM, mas cabe no L2ARC, será muito mais rápida do que uma DDT que deve ler do disco. Os limites na taxa de dados adicionados aos dispositivos de cache evitam o desgaste prematuro dos SSDs com gravações extras. Até que o cache esteja cheio (o primeiro bloco despejado para liberar espaço), grava no limite L2ARC até a soma do limite de gravação e do limite de aumento e depois limita ao limite de gravação. Um par de valores sysctl(8) controla esses limites de taxa. vfs.zfs.l2arc_write_max controla o número de bytes gravados no cache por segundo, enquanto vfs.zfs.l2arc_write_boost aumenta esse limite durante a “fase de aquecimento do turbo” (aumento de gravação).
ZIL	ZIL acelera transações síncronas usando dispositivos de armazenamento como SSDs que são mais rápidos do que aqueles usados ​​no pool de armazenamento principal. Quando um aplicativo solicita uma gravação síncrona (uma garantia de que os dados são armazenados em disco em vez de apenas armazenados em cache para gravações posteriores), gravar os dados no armazenamento ZIL mais rápido e depois descarregá-los nos discos regulares reduz muito a latência e melhora o desempenho. Cargas de trabalho síncronas, como bancos de dados, lucrarão apenas com um ZIL. Gravações assíncronas regulares, como copiar arquivos, não usarão o ZIL.
Copy-On-Write	Ao contrário de um sistema de arquivos tradicional, o ZFS grava um bloco diferente em vez de substituir os dados antigos no local. Ao concluir isso, escreve as atualizações de metadados para apontar para o novo local. Quando ocorre uma gravação curta (uma falha no sistema ou perda de energia no meio da gravação de um arquivo), todo o conteúdo original do arquivo ainda está disponível e o ZFS descarta a gravação incompleta. Isso também significa que o ZFS não requer um fsck após um desligamento inesperado. fsck é um utilitário de sistema no Linux usado para verificar e reparar erros em sistemas de arquivos.
Dataset	dataset ou Conjunto de dados é o termo genérico para um sistema de arquivos ZFS, volume, instantâneo ou clone. Cada conjunto de dados tem um nome exclusivo no formato poolname/path@snapshot. A raiz do pool também é um conjunto de dados. Os conjuntos de dados filhos têm nomes hierárquicos como diretórios. Por exemplo, mypool/home, o conjunto de dados inicial, é filho de mypool e herda propriedades dele. Expanda ainda mais criando mypool/home/user. Este conjunto de dados neto herdará as propriedades do pai e do avô. Defina as propriedades de um filho para substituir os padrões herdados do pai e do avô. A administração de dataset(conjuntos de dados) e seus filhos pode ser delegada.
Sistema de arquivos	Um dataset ZFS é usado com mais frequência como um sistema de arquivos. Como a maioria dos outros sistemas de arquivos, um sistema de arquivos ZFS é montado em algum lugar na hierarquia de diretórios do sistema e contém seus próprios arquivos e diretórios com permissões, sinalizadores(flags) e outros metadados.
Volume	O ZFS também pode criar volumes, que aparecem como dispositivos de disco. Os volumes têm muitos dos mesmos recursos que os datasets, incluindo cópia na gravação, instantâneos, clones e soma de verificação. Os volumes podem ser úteis para executar outros formatos de sistema de arquivos no ZFS, como virtualização UFS ou exportar extensões iSCSI.
SnapShot	O design copy-on-write (COW) do ZFS permite snapshots(instantâneos) quase instantâneos e consistentes com nomes arbitrários. Depois de tirar um snapshot de um dataset ou um snapshot recursivo de um dataset pai que incluirá todos os datasets filhos, os novos dados vão para novos blocos, mas sem recuperar os blocos antigos como espaço livre. O snapshot contém a versão original do sistema de arquivos e o sistema de arquivos ao vivo contém todas as alterações feitas desde a obtenção do snapshot sem usar outro espaço. Novos dados gravados no sistema de arquivos ao vivo usam novos blocos para armazenar esses dados. O snapshot aumentará à medida que os blocos não forem mais usados ​​no sistema de arquivos ao vivo, mas apenas no snapshot. Montar esses instantâneos somente leitura permite a recuperação de versões de arquivos anteriores. Uma reversão de um sistema de arquivos ao vivo para um snapshot específico é possível, desfazendo todas as alterações que ocorreram após a captura do snapshot. Cada bloco no pool tem um contador de referência que rastreia os snapshots, clones, dataset ou volumes que usam esse bloco. À medida que arquivos e snapshots são excluídos, a contagem de referência diminui, recuperando o espaço livre quando não faz mais referência a um bloco. Marcar snapshots com um hold(retenção) resulta em qualquer tentativa de destruí-lo, retornará um erro EBUSY. Cada snapshot pode ter retenções com um nome exclusivo cada. O comando release remove a retenção para que o instantâneo possa ser excluído. Snapshots, cloning, and rolling back funcionam em volumes, mas a montagem independente não.
Clone	A clonagem de um snapshot também é possível. Um clone é uma versão gravável de um instantâneo, permitindo que o sistema de arquivos se bifurque como um novo dataset. Assim como um snapshot, um clone inicialmente não consome nenhum espaço novo. À medida que novos dados gravados em um clone usam novos blocos, o tamanho do clone aumenta. Quando os blocos são substituídos no sistema de arquivos ou volume clonado, a contagem de referência no bloco anterior diminui. Remover o snapshot no qual um clone se baseia é impossível porque o clone depende dele. O snapshot é o pai e o clone é o filho. Os clones podem ser promovidos, revertendo essa dependência e tornando o clone o pai e o pai anterior o filho. Esta operação não requer nenhum novo espaço. Como a quantidade de espaço usada pelo pai e pelo filho se inverte, isso pode afetar as cotas e reservas existentes.
Checksum	Cada bloco também é realizado um Checksum(ou soma de verificação). O algoritmo de soma de verificação(checksum) usado é uma propriedade por conjunto de dados, consulte set. A soma de verificação de cada bloco é validada de forma transparente quando lida, permitindo que o ZFS detecte corrupção silenciosa. Se os dados lidos não corresponderem à soma de verificação esperada, o ZFS tentará recuperar os dados de qualquer redundância disponível, como espelhos ou RAID-Z. Acionando uma validação de todas as somas de verificação com scrub. Os algoritmos de soma de verificação incluem: * flettcher2 * fletcher4 * sha256 Os algoritmos fletcher são mais rápidos, mas sha256 é um forte hash criptográfico e tem uma chance muito menor de colisões ao custo de algum desempenho. A desativação das somas de verificação é possível, mas fortemente desencorajada.
Compressão	Cada dataset tem uma propriedade de compactação cujo padrão é desativado. Configure esta propriedade para um algoritmo de compactação disponível. Isso causa a compactação de todos os novos dados gravados no dataset. Além de uma redução no espaço usado, a taxa de transferência de leitura e gravação geralmente aumenta porque menos blocos precisam ser lidos ou gravados. * LZ4 – Adicionado no pool ZFS versão 5000 (sinalizadores de recursos), LZ4 agora é o algoritmo de compactação recomendado. O LZ4 funciona cerca de 50% mais rápido que o LZJB ao operar em dados compressíveis e é três vezes mais rápido ao operar em dados não-compressíveis. O LZ4 também descompacta cerca de 80% mais rápido que o LZJB. Em CPUs modernas, o LZ4 geralmente pode compactar a mais de 500 MB/s e descompactar a mais de 1,5 GB/s (por único núcleo da CPU). * LZJB – O algoritmo de compressão padrão. Criado por Jeff Bonwick (um dos criadores originais do ZFS). LZJB oferece boa compactação com menos sobrecarga de CPU em comparação com GZIP. No futuro, o algoritmo de compactação padrão mudará para LZ4. * GZIP – Um algoritmo popular de compactação de fluxo disponível no ZFS. Uma das principais vantagens de usar GZIP é seu nível de compressão configurável. Ao definir a propriedade compress, o administrador pode escolher o nível de compactação, variando de gzip1, o nível mais baixo de compactação, a gzip9, o nível mais alto de compactação. Isso dá ao administrador controle sobre quanto tempo de CPU deve ser trocado por espaço em disco economizado. * ZLE – Zero Length Encoding é um algoritmo de compressão especial que comprime execuções contínuas de zeros sozinho. Esse algoritmo de compactação é útil quando o conjunto de dados contém grandes blocos de zeros.
Copies	Quando definido com um valor maior que 1, a propriedade copys instrui o ZFS a manter cópias de cada bloco no sistema de arquivos ou volume. Definir essa propriedade em conjuntos de dados importantes fornece redundância adicional para recuperar um bloco que não corresponde à sua soma de verificação. Em pools sem redundância, o recurso de cópias é a única forma de redundância. O recurso de cópias pode recuperar de um único setor defeituoso ou outras formas de corrupção menor, mas não protege o pool da perda de um disco inteiro.
Desduplicação	As somas de verificação(checksums) permitem detectar blocos duplicados ao gravar dados. Com a desduplicação, a contagem de referência de um bloco idêntico existente aumenta, economizando espaço de armazenamento. O ZFS mantém uma tabela de desduplicação (DDT) na memória para detectar blocos duplicados. A tabela contém uma lista de somas de verificação exclusivas, a localização desses blocos e uma contagem de referência. Ao gravar novos dados, o ZFS calcula as somas de verificação e as compara com a lista. Ao encontrar uma correspondência, ele usa o bloco existente. O uso do algoritmo de soma de verificação SHA256 com desduplicação fornece um hash criptográfico seguro. A desduplicação é ajustável. Se a deduplicação estiver ativada, uma soma de verificação correspondente significa que os dados são idênticos. Configurando a deduplicação para verificar, o ZFS executa uma verificação byte a byte nos dados, garantindo que sejam realmente idênticos. Se os dados não forem idênticos, o ZFS observará a colisão de hash e armazenará os dois blocos separadamente. Como o DDT deve armazenar o hash de cada bloco único, ele consome uma grande quantidade de memória. Uma regra geral é 5-6 GB de RAM por 1 TB de dados desduplicados). Em situações não práticas para ter RAM suficiente para manter todo o DDT na memória, o desempenho será muito prejudicado, pois o DDT deve ler o disco antes de gravar cada novo bloco. A desduplicação pode usar o L2ARC para armazenar o DDT, fornecendo um meio termo entre a memória rápida do sistema e os discos mais lentos. Em vez disso, considere usar compactação, que geralmente oferece quase a mesma economia de espaço sem aumentar a memória.
Scrub	Em vez de uma verificação de consistência como fsck(8), o ZFS tem scrub. scrub lê todos os blocos de dados armazenados no pool e verifica suas somas de verificação em relação às somas de verificação boas conhecidas armazenadas nos metadados. Uma verificação periódica de todos os dados armazenados no pool garante a recuperação de quaisquer blocos corrompidos antes de precisar deles. Não é necessário esfregar após um desligamento impuro, mas uma boa prática é pelo menos uma vez a cada três meses. O ZFS verifica a soma de verificação de cada bloco durante o uso normal, mas uma limpeza garante a verificação mesmo de blocos usados ​​com pouca frequência quanto à corrupção silenciosa. O ZFS melhora a segurança dos dados em situações de armazenamento de arquivos. Ajuste a prioridade relativa do scrub com vfs.zfs.scrub_delay para evitar que o scrub degrade o desempenho de outras cargas de trabalho no pool.
Dataset Quota	O ZFS fornece dataset rápido e preciso, usuário e contabilidade de espaço de grupo, bem como cotas e reservas de espaço. Isso dá ao administrador um controle refinado sobre a alocação de espaço e permite a reserva de espaço para sistemas de arquivos críticos. ZFS oferece suporte a diferentes tipos de cotas: a cota do conjunto de dados, a cota de referência (refquota), a cota do usuário e a cota do grupo. As cotas limitam o tamanho total de um conjunto de dados e seus descendentes, incluindo instantâneos do conjunto de dados, conjuntos de dados filhos e instantâneos desses conjuntos de dados. Observação:  Os volumes não suportam cotas, pois a propriedade volsize age como uma cota implícita.
Reference Quota ou Cota de referência	As cotas de usuário são úteis para limitar a quantidade de espaço usado pelo usuário especificado.
User Quota ou Cota de usuário	As cotas de usuário são úteis para limitar a quantidade de espaço usado pelo usuário especificado.
Group Quota ou cota de grupo	A cota do grupo limita a quantidade de espaço que um grupo especificado pode consumir.
Dataset Reservation ou Reserva de conjunto de dados	A propriedade de reserva permite garantir uma quantidade de espaço para um conjunto de dados específico e seus descendentes. Isso significa que definir uma reserva de 10 GB em storage/home/bob evita que outros conjuntos de dados usem todo o espaço livre, reservando pelo menos 10 GB de espaço para este conjunto de dados. Ao contrário de uma reserva regular, o espaço usado por instantâneos e descendentes não é contabilizado na reserva. Por exemplo, se estiver tirando um instantâneo de storage/home/bob, deve existir espaço em disco suficiente além do valor de reserva para que a operação seja bem-sucedida. Os descendentes do conjunto de dados principal não são contados no valor da reserva e, portanto, não invadem o espaço definido. Reservas de qualquer tipo são úteis em situações como planejamento e teste da adequação da alocação de espaço em disco em um novo sistema ou garantia de que haja espaço suficiente disponível nos sistemas de arquivos para logs de áudio ou procedimentos e arquivos de recuperação do sistema.
Reference Reservation ou Reserva de referência	A propriedade refreservation permite garantir uma quantidade de espaço para o uso de um conjunto de dados específico excluindo seus descendentes. Isso significa que definir uma reserva de 10 GB em storage/home/bob e outro conjunto de dados tenta usar o espaço livre, reservando pelo menos 10 GB de espaço para este conjunto de dados. Ao contrário de uma reserva normal, o espaço usado por instantâneos e conjuntos de dados descendentes não é contabilizado na reserva. Por exemplo, se estiver tirando um instantâneo de storage/home/bob, deve existir espaço em disco suficiente além do valor de reserva para que a operação seja bem-sucedida. Os descendentes do conjunto de dados principal não são contados no valor da reserva e, portanto, não invadem o espaço definido.
Resilver	Ao substituir um disco com falha, o ZFS deve preencher o novo disco com os dados perdidos. Resilvering é o processo de usar as informações de paridade distribuídas pelas unidades restantes para calcular e gravar os dados ausentes na nova unidade.
Online	Um pool ou vdev no estado Online tem seus dispositivos membros conectados e totalmente operacionais. Dispositivos individuais no estado Online estão funcionando.
Offline	O administrador coloca dispositivos individuais em um estado Offline se houver redundância suficiente para evitar colocar o pool ou vdev em um estado com falha. Um administrador pode optar por colocar um disco off-line em preparação para substituí-lo ou para torná-lo mais fácil de identificar.
Degraded ou degradado	Um pool ou vdev no estado Degradado tem um ou mais discos que desapareceram ou falharam. O pool ainda pode ser usado, mas se outros dispositivos falharem, o pool pode se tornar irrecuperável. Reconectar os dispositivos ausentes ou substituir os discos com falha retornará o pool a um estado Online depois que o novo dispositivo ou reconectado tiver concluído o processo Resilver.
Faulted ou com defeito	Um pool ou vdev no estado com falha não está mais operacional. O acesso aos dados não é mais possível. Um pool ou vdev entra no estado com falha quando o número de dispositivos ausentes ou com falha excede o nível de redundância no vdev. Se reconectar os dispositivos ausentes, o pool retornará ao estado Online. A redundância insuficiente para compensar o número de discos com falha perde o conteúdo do pool e requer restauração de backups.

Fonte: docs.freebsd