19.3. Administração `zpool`
Anterior | Capítulo 19. O sistema de arquivos Z (ZFS) | Próxima

## 19.3. Administração `zpool`

A administração do ZFS é dividida entre dois utilitários principais. O utilitário `zpool` controla a operação do pool e trata da adição, remoção, substituição e gerenciamento de discos. O utilitário `zfs` lida com a criação, destruição e gerenciamento de datasets, tanto para sistemas de arquivos quanto para volumes.

### 19.3.1. Criando e destruindo pools de armazenamento

A criação de um pool de armazenamento do ZFS (zpool) envolve a tomada de várias decisões que são relativamente permanentes porque a estrutura do pool não pode ser alterada depois que o pool é criado. A decisão mais importante é quais tipos de vdevs usar para agrupar os discos físicos. Consulte a lista de tipos vdev para obter detalhes sobre as opções possíveis. Após o pool ter sido criado, a maioria dos tipos de vdev não permite que discos adicionais sejam adicionados ao vdev. As exceções são os mirrors, que permitem que discos adicionais sejam adicionados ao vdev, e stripes, que podem ser atualizados para mirrors ao anexar um disco adicional ao vdev. Embora vdevs adicionais possam ser adicionados para expandir um pool, o layout do pool não pode ser alterado após a criação do pool. Em vez disso, os dados devem ser salvos em um backup e o pool destruído e recriado.

Crie um pool do tipo mirror simples:

    # zpool create mypool mirror /dev/ada1 /dev/ada2
    # zpool status
      pool: mypool
     state: ONLINE
      scan: none requested
    config:

            NAME        STATE     READ WRITE CKSUM
            mypool      ONLINE       0     0     0
              mirror-0  ONLINE       0     0     0
                ada1    ONLINE       0     0     0
                ada2    ONLINE       0     0     0

    errors: No known data errors

Vários vdevs podem ser criados de uma só vez. Especifique vários grupos de discos separados pela palavra-chave do tipo vdev, `mirror` neste exemplo:

    # zpool create mypool mirror /dev/ada1 /dev/ada2 mirror /dev/ada3 /dev/ada4
      pool: mypool
     state: ONLINE
      scan: none requested
    config:

            NAME        STATE     READ WRITE CKSUM
            mypool      ONLINE       0     0     0
              mirror-0  ONLINE       0     0     0
                ada1    ONLINE       0     0     0
                ada2    ONLINE       0     0     0
              mirror-1  ONLINE       0     0     0
                ada3    ONLINE       0     0     0
                ada4    ONLINE       0     0     0

    errors: No known data errors

Os pools também podem ser construídos usando partições em vez de discos inteiros. Colocar o ZFS em uma partição separada permite que o mesmo disco tenha outras partições para outras finalidades. Em particular, partições com bootcode e sistemas de arquivos necessários para a inicialização podem ser adicionadas. Isso permite inicializar a partir de discos que também são membros de um pool. Não há penalidade de desempenho no FreeBSD ao usar uma partição em vez de um disco inteiro. O uso de partições também permite ao administrador sub-provisionar os discos, usando menos que a capacidade total. Se um disco de substituição futuro com o mesmo tamanho nominal do original tiver uma capacidade ligeiramente menor, a partição menor ainda se ajustará e o disco de substituição ainda poderá ser usado.

Crie um pool RAID-Z2 usando partições:

    # zpool create mypool raidz2 /dev/ada0p3 /dev/ada1p3 /dev/ada2p3 /dev/ada3p3 /dev/ada4p3 /dev/ada5p3
    # zpool status
      pool: mypool
     state: ONLINE
      scan: none requested
    config:

            NAME        STATE     READ WRITE CKSUM
            mypool      ONLINE       0     0     0
              raidz2-0  ONLINE       0     0     0
                ada0p3  ONLINE       0     0     0
                ada1p3  ONLINE       0     0     0
                ada2p3  ONLINE       0     0     0
                ada3p3  ONLINE       0     0     0
                ada4p3  ONLINE       0     0     0
                ada5p3  ONLINE       0     0     0

    errors: No known data errors

Um pool que não é mais necessário pode ser destruído para que os discos possam ser reutilizados. Destruir um pool envolve primeiro desmontar todos os datasets nesse pool. Se os datasets estiverem em uso, a operação de desmontagem falhará e o pool não será destruído. A destruição do pool pode ser forçada com `-f`, mas isso pode causar um comportamento indefinido em aplicações que tiverem arquivos abertos nesses datasets.

### 19.3.2. Adicionando e Removendo Dispositivos

Existem dois casos para adicionar discos a um zpool: anexar um disco a um vdev existente com `zpool attach` ou incluir vdevs ao pool com `zpool add` . Apenas alguns vdev types permitem que discos sejam adicionados ao vdev após a criação.

Um pool criado com um único disco não tem redundância. Dados corrompidos podem ser detectados, mas não reparados, porque não há outra cópia dos dados. A propriedade copies pode ser capaz de se recuperar de uma pequena falha, como um setor defeituoso, mas não fornece o mesmo nível de proteção que o mirror ou o RAID-Z. Começando com um pool de um único disco vdev, o `zpool attach` pode ser usado para adicionar um disco adicional ao vdev, criando um mirror. O `zpool attach` também pode ser usado para adicionar discos adicionais a um mirror group, aumentando a redundância e o desempenho de leitura. Se os discos usados ​​para o pool forem particionados, replicar o layout do primeiro disco para o segundo, `gpart backup` e `gpart restore` pode ser usado para facilitar esse processo .

Atualize o disco único (stripe) vdev `ada0p3` para um mirror anexando `ada1p3`:

    # zpool status
      pool: mypool
     state: ONLINE
      scan: none requested
    config:

            NAME        STATE     READ WRITE CKSUM
            mypool      ONLINE       0     0     0
              ada0p3    ONLINE       0     0     0

    errors: No known data errors
    # zpool attach mypool ada0p3 ada1p3
    Make sure to wait until resilver is done before rebooting.

    If you boot from pool 'mypool', you may need to update
    boot code on newly attached disk 'ada1p3'.

    Assuming you use GPT partitioning and 'da0' is your new boot disk
    you may use the following command:

            gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0
    # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada1
    bootcode written to ada1
    # zpool status
      pool: mypool
     state: ONLINE
    status: One or more devices is currently being resilvered.  The pool will
            continue to function, possibly in a degraded state.
    action: Wait for the resilver to complete.
      scan: resilver in progress since Fri May 30 08:19:19 2014
            527M scanned out of 781M at 47.9M/s, 0h0m to go
            527M resilvered, 67.53% done
    config:

            NAME        STATE     READ WRITE CKSUM
            mypool      ONLINE       0     0     0
              mirror-0  ONLINE       0     0     0
                ada0p3  ONLINE       0     0     0
                ada1p3  ONLINE       0     0     0  (resilvering)

    errors: No known data errors
    # zpool status
      pool: mypool
     state: ONLINE
      scan: resilvered 781M in 0h0m with 0 errors on Fri May 30 08:15:58 2014
    config:

            NAME        STATE     READ WRITE CKSUM
            mypool      ONLINE       0     0     0
              mirror-0  ONLINE       0     0     0
                ada0p3  ONLINE       0     0     0
                ada1p3  ONLINE       0     0     0

    errors: No known data errors

Quando adicionar discos ao vdev existente não é uma opção, como para RAID-Z, um método alternativo é adicionar outro vdev ao pool. Vdevs adicionais fornecem desempenho mais alto, distribuindo as operações de escrita nos vdevs. Cada vdev é responsável por fornecer a sua própria redundância. É possível, mas desencorajado, misturar tipos de vdev, como `mirror` e `RAID-Z`. Adicionar um vdev não-redundante a um pool que contenha um vdev mirror ou o RAID-Z arrisca os dados em todo o pool. As gravações são distribuídas, portanto, a falha do disco não-redundante resultará na perda de uma fração de cada bloco que foi gravado no pool.

Os dados são distribuídos em cada um dos vdevs. Por exemplo, com dois vdevs mirror, esse é efetivamente um RAID 10 que escreve em dois conjuntos de mirrors. O espaço é alocado de forma que cada vdev chegue a 100% de uso ao mesmo tempo. Há uma penalidade de desempenho se os vdevs tiverem quantidades diferentes de espaço livre, pois uma quantidade desproporcional dos dados é gravada no vdev menos cheio.

Ao anexar dispositivos adicionais a um pool de inicialização, lembre-se de atualizar o bootcode.

Anexe um segundo grupo de mirror's (`ada2p3` and `ada3p3`) ao mirror existente:

    # zpool status
      pool: mypool
     state: ONLINE
      scan: resilvered 781M in 0h0m with 0 errors on Fri May 30 08:19:35 2014
    config:

            NAME        STATE     READ WRITE CKSUM
            mypool      ONLINE       0     0     0
              mirror-0  ONLINE       0     0     0
                ada0p3  ONLINE       0     0     0
                ada1p3  ONLINE       0     0     0

    errors: No known data errors
    # zpool add mypool mirror ada2p3 ada3p3
    # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada2
    bootcode written to ada2
    # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada3
    bootcode written to ada3
    # zpool status
      pool: mypool
     state: ONLINE
      scan: scrub repaired 0 in 0h0m with 0 errors on Fri May 30 08:29:51 2014
    config:

            NAME        STATE     READ WRITE CKSUM
            mypool      ONLINE       0     0     0
              mirror-0  ONLINE       0     0     0
                ada0p3  ONLINE       0     0     0
                ada1p3  ONLINE       0     0     0
              mirror-1  ONLINE       0     0     0
                ada2p3  ONLINE       0     0     0
                ada3p3  ONLINE       0     0     0

    errors: No known data errors

Atualmente, os vdevs não podem ser removidos de um pool e os discos só podem ser removidos de um mirror se houver redundância restante suficiente. Se apenas um disco em um grupo de mirror's permanecer, ele deixará de ser um mirror e voltará a ser um srtipe, arriscando todo o pool se o disco restante falhar.

Remova um disco de um grupo de mirror's triplo:

    # zpool status
      pool: mypool
     state: ONLINE
      scan: scrub repaired 0 in 0h0m with 0 errors on Fri May 30 08:29:51 2014
    config:

            NAME        STATE     READ WRITE CKSUM
            mypool      ONLINE       0     0     0
              mirror-0  ONLINE       0     0     0
                ada0p3  ONLINE       0     0     0
                ada1p3  ONLINE       0     0     0
                ada2p3  ONLINE       0     0     0

    errors: No known data errors
    # zpool detach mypool ada2p3
    # zpool status
      pool: mypool
     state: ONLINE
      scan: scrub repaired 0 in 0h0m with 0 errors on Fri May 30 08:29:51 2014
    config:

            NAME        STATE     READ WRITE CKSUM
            mypool      ONLINE       0     0     0
              mirror-0  ONLINE       0     0     0
                ada0p3  ONLINE       0     0     0
                ada1p3  ONLINE       0     0     0

    errors: No known data errors

### 19.3.3. Verificando o status de um pool

O status do pool é importante. Se uma unidade ficar off-line ou for detectado um erro de leitura, gravação ou de checksum, a contagem de erros correspondente aumentará. A saída `status` mostra a configuração e o status de cada dispositivo no pool e o status de todo o pool. Ações que precisam ser tomadas e detalhes sobre o último `scrub` também são mostrados.

    # zpool status
      pool: mypool
     state: ONLINE
      scan: scrub repaired 0 in 2h25m with 0 errors on Sat Sep 14 04:25:50 2013
    config:

            NAME        STATE     READ WRITE CKSUM
            mypool      ONLINE       0     0     0
              raidz2-0  ONLINE       0     0     0
                ada0p3  ONLINE       0     0     0
                ada1p3  ONLINE       0     0     0
                ada2p3  ONLINE       0     0     0
                ada3p3  ONLINE       0     0     0
                ada4p3  ONLINE       0     0     0
                ada5p3  ONLINE       0     0     0

    errors: No known data errors

### 19.3.4. Limpando Erros

Quando um erro é detectado, os contadores de leitura, escrita ou checksum são incrementados. A mensagem de erro pode ser apagada e os contadores resetados com `zpool clear `mypool``. Limpar o estado de erro pode ser importante para scripts automatizados que alertam o administrador quando o pool encontra um erro. Erros adicionais podem não ser relatados se os erros antigos não forem apagados.

### 19.3.5. Substituindo um dispositivo em funcionamento

Há várias situações em que pode ser desejável substituir um disco por um disco diferente. Ao substituir um disco em funcionamento, o processo mantém o disco antigo online durante a substituição. O pool nunca entra no estado degradado , reduzindo o risco de perda de dados. `zpool replace` copia todos os dados do disco antigo para o novo. Após a conclusão da operação, o disco antigo é desconectado do vdev. Se o novo disco for maior que o disco antigo, pode ser possível aumentar o zpool usando o novo espaço. Veja Aumentando um Pool .

Substitua um dispositivo em funcionamento no pool:

    # zpool status
      pool: mypool
     state: ONLINE
      scan: none requested
    config:

            NAME        STATE     READ WRITE CKSUM
            mypool      ONLINE       0     0     0
              mirror-0  ONLINE       0     0     0
                ada0p3  ONLINE       0     0     0
                ada1p3  ONLINE       0     0     0

    errors: No known data errors
    # zpool replace mypool ada1p3 ada2p3
    Make sure to wait until resilver is done before rebooting.

    If you boot from pool 'zroot', you may need to update
    boot code on newly attached disk 'ada2p3'.

    Assuming you use GPT partitioning and 'da0' is your new boot disk
    you may use the following command:

            gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 da0
    # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada2
    # zpool status
      pool: mypool
     state: ONLINE
    status: One or more devices is currently being resilvered.  The pool will
            continue to function, possibly in a degraded state.
    action: Wait for the resilver to complete.
      scan: resilver in progress since Mon Jun  2 14:21:35 2014
            604M scanned out of 781M at 46.5M/s, 0h0m to go
            604M resilvered, 77.39% done
    config:

            NAME             STATE     READ WRITE CKSUM
            mypool           ONLINE       0     0     0
              mirror-0       ONLINE       0     0     0
                ada0p3       ONLINE       0     0     0
                replacing-1  ONLINE       0     0     0
                  ada1p3     ONLINE       0     0     0
                  ada2p3     ONLINE       0     0     0  (resilvering)

    errors: No known data errors
    # zpool status
      pool: mypool
     state: ONLINE
      scan: resilvered 781M in 0h0m with 0 errors on Mon Jun  2 14:21:52 2014
    config:

            NAME        STATE     READ WRITE CKSUM
            mypool      ONLINE       0     0     0
              mirror-0  ONLINE       0     0     0
                ada0p3  ONLINE       0     0     0
                ada2p3  ONLINE       0     0     0

    errors: No known data errors

### 19.3.6. Lidando com dispositivos com falha

Quando um disco em um pool falha, o vdev ao qual o disco pertence entra no estado degradado. Todos os dados ainda estão disponíveis, mas o desempenho pode ser reduzido porque os dados ausentes devem ser calculados a partir da redundância disponível. Para restaurar o vdev para um estado totalmente funcional, o dispositivo físico com falha deve ser substituído. O ZFS é então instruído a iniciar a operação resilver. Os dados que estavam no dispositivo com falha são recalculados da redundância disponível e gravados no dispositivo de substituição. Após a conclusão, o vdev retorna ao status online.

Se o vdev não tiver redundância, ou se vários dispositivos falharem e não houver redundância suficiente para compensar, o pool entrará no estado failed. Se um número suficiente de dispositivos não puder ser reconectado ao pool, o pool se tornará inoperante e os dados deverão ser restaurados dos backups.

Ao substituir um disco com falha, o nome do disco com falha é substituído pelo GUID do dispositivo. Um novo parâmetro de nome de dispositivo para o `zpool replace` não é necessário se o dispositivo de substituição tiver o mesmo nome de dispositivo.

Substitua um disco com falha usando o `zpool replace`:

    # zpool status
      pool: mypool
     state: DEGRADED
    status: One or more devices could not be opened.  Sufficient replicas exist for
            the pool to continue functioning in a degraded state.
    action: Attach the missing device and online it using 'zpool online'.
       see: http://illumos.org/msg/ZFS-8000-2Q
      scan: none requested
    config:

            NAME                    STATE     READ WRITE CKSUM
            mypool                  DEGRADED     0     0     0
              mirror-0              DEGRADED     0     0     0
                ada0p3              ONLINE       0     0     0
                316502962686821739  UNAVAIL      0     0     0  was /dev/ada1p3

    errors: No known data errors
    # zpool replace mypool 316502962686821739 ada2p3
    # zpool status
      pool: mypool
     state: DEGRADED
    status: One or more devices is currently being resilvered.  The pool will
            continue to function, possibly in a degraded state.
    action: Wait for the resilver to complete.
      scan: resilver in progress since Mon Jun  2 14:52:21 2014
            641M scanned out of 781M at 49.3M/s, 0h0m to go
            640M resilvered, 82.04% done
    config:

            NAME                        STATE     READ WRITE CKSUM
            mypool                      DEGRADED     0     0     0
              mirror-0                  DEGRADED     0     0     0
                ada0p3                  ONLINE       0     0     0
                replacing-1             UNAVAIL      0     0     0
                  15732067398082357289  UNAVAIL      0     0     0  was /dev/ada1p3/old
                  ada2p3                ONLINE       0     0     0  (resilvering)

    errors: No known data errors
    # zpool status
      pool: mypool
     state: ONLINE
      scan: resilvered 781M in 0h0m with 0 errors on Mon Jun  2 14:52:38 2014
    config:

            NAME        STATE     READ WRITE CKSUM
            mypool      ONLINE       0     0     0
              mirror-0  ONLINE       0     0     0
                ada0p3  ONLINE       0     0     0
                ada2p3  ONLINE       0     0     0

    errors: No known data errors

### 19.3.7. Limpeza do Pool

Recomenda-se que os pools sejam regularmente scrubbed, idealmente pelo menos uma vez por mês. A operação `scrub` requer muito disco e reduzirá o desempenho durante a execução. Evite períodos de alta demanda ao agendar o `scrub` ou use `vfs.zfs.scrub_delay` para ajustar a prioridade relativa do `scrub` para evitar que ele interfira com outras cargas de trabalho.

    # zpool scrub mypool
    # zpool status
      pool: mypool
     state: ONLINE
      scan: scrub in progress since Wed Feb 19 20:52:54 2014
            116G scanned out of 8.60T at 649M/s, 3h48m to go
            0 repaired, 1.32% done
    config:

            NAME        STATE     READ WRITE CKSUM
            mypool      ONLINE       0     0     0
              raidz2-0  ONLINE       0     0     0
                ada0p3  ONLINE       0     0     0
                ada1p3  ONLINE       0     0     0
                ada2p3  ONLINE       0     0     0
                ada3p3  ONLINE       0     0     0
                ada4p3  ONLINE       0     0     0
                ada5p3  ONLINE       0     0     0

    errors: No known data errors

No caso de uma operação de limpeza precisar ser cancelada, emita `zpool scrub -s `mypool``.

### 19.3.8. Auto Cura (Self-Healing)

Os checksums armazenados com os blocos de dados habilitam o sistema de arquivos a se autocorrigirem. Esse recurso reparará automaticamente os dados cujo checksum não corresponde à registrada em outro dispositivo que faz parte do pool de armazenamento. Por exemplo, um espelho com dois discos em que uma unidade está começando a funcionar incorretamente e não pode armazenar os dados adequadamente. Isso é ainda pior quando os dados não são acessados ​​há muito tempo, como no armazenamento de arquivos de longo prazo. Os sistemas de arquivos tradicionais precisam executar algoritmos que verificam e reparam os dados como o fsck(8). Esses comandos levam tempo e, em casos graves, um administrador precisa decidir manualmente qual operação de reparo deve ser executada. Quando o ZFS detecta um bloco de dados com um checksum que não corresponde, ele tenta ler os dados do disco de espelhamento. Se esse disco puder fornecer os dados corretos, ele não apenas fornecerá esses dados ao aplicativo que os está solicitando, mas também corrigirá os dados errados no disco que continha o checksum incorreto. Isso acontece sem qualquer interação de um administrador do sistema durante a operação normal do pool.

O próximo exemplo demonstra esse comportamento de autocura. Um conjunto espelhado de discos `/dev/ada0` e `/dev/ada1` é criado.

    # zpool create healer mirror /dev/ada0 /dev/ada1
    # zpool status healer
      pool: healer
     state: ONLINE
      scan: none requested
    config:

        NAME        STATE     READ WRITE CKSUM
        healer      ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
           ada0     ONLINE       0     0     0
           ada1     ONLINE       0     0     0

    errors: No known data errors
    # zpool list
    NAME     SIZE  ALLOC   FREE   CKPOINT  EXPANDSZ   FRAG   CAP  DEDUP  HEALTH  ALTROOT
    healer   960M  92.5K   960M         -         -     0%    0%  1.00x  ONLINE  -

Alguns dados importantes que devem ser protegidos de erros de dados usando o recurso de correção automática são copiados para o pool. É criado um checksum do pool para comparação posterior.

    # cp /some/important/data /healer
    # zfs list
    NAME     SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
    healer   960M  67.7M   892M     7%  1.00x  ONLINE  -
    # sha1 /healer > checksum.txt
    # cat checksum.txt
    SHA1 (/healer) = 2753eff56d77d9a536ece6694bf0a82740344d1f

A corrupção de dados é simulada escrevendo dados aleatórios no início de um dos discos no espelho. Para evitar que o ZFS cure os dados assim que forem detectados, o pool é exportado antes da corrupção e importado novamente depois.

### Atenção:

Esta é uma operação perigosa que pode destruir dados vitais. Ele é mostrado aqui apenas para fins demonstrativos e não deve ser tentado durante a operação normal de um pool de armazenamento. Nem este exemplo de corrupção intencional deve ser executado em qualquer disco com um sistema de arquivos diferente. Não use outros nomes de dispositivos de disco diferentes daqueles que fazem parte do pool. Certifique-se de que os backups apropriados do pool sejam criados antes de executar o comando!

    # zpool export healer
    # dd if=/dev/random of=/dev/ada1 bs=1m count=200
    200+0 records in
    200+0 records out
    209715200 bytes transferred in 62.992162 secs (3329227 bytes/sec)
    # zpool import healer

O status do pool mostra que um dispositivo teve um erro. Observe que os aplicativos que leem dados do pool não receberam dados incorretos. O ZFS forneceu dados do dispositivo `ada0` com os checksums corretos. O dispositivo com o checksum incorreto pode ser encontrado facilmente, pois a coluna `CKSUM` contém um valor diferente de zero.

    # zpool status healer
        pool: healer
       state: ONLINE
      status: One or more devices has experienced an unrecoverable error.  An
              attempt was made to correct the error.  Applications are unaffected.
      action: Determine if the device needs to be replaced, and clear the errors
              using 'zpool clear' or replace the device with 'zpool replace'.
         see: http://illumos.org/msg/ZFS-8000-4J
        scan: none requested
      config:

          NAME        STATE     READ WRITE CKSUM
          healer      ONLINE       0     0     0
            mirror-0  ONLINE       0     0     0
             ada0     ONLINE       0     0     0
             ada1     ONLINE       0     0     1

    errors: No known data errors

O erro foi detectado e tratado usando a redundância presente no disco de espelhamento `ada0` não afetado. Uma comparação de checksum com o original irá revelar se o pool está consistente novamente.

    # sha1 /healer >> checksum.txt
    # cat checksum.txt
    SHA1 (/healer) = 2753eff56d77d9a536ece6694bf0a82740344d1f
    SHA1 (/healer) = 2753eff56d77d9a536ece6694bf0a82740344d1f

Os dois checksums que foram gerados antes e depois da adulteração intencional dos dados do conjunto ainda correspondem. Isso mostra como o ZFS é capaz de detectar e corrigir erros automaticamente quando os checksums são diferentes. Observe que isso só é possível quando há redundância suficiente presente no pool. Um pool que consiste em um único dispositivo não possui recursos de autocorreção. Essa também é a razão pela qual os cheksuma são tão importantes no ZFS e não devem ser desabilitados por nenhum motivo. Nenhum fsck(8) ou programa semelhante de verificação de consistência do sistema de arquivos é necessário para detectar e corrigir isso e o pool ainda estava disponível durante o problema. Uma operação de scrub agora é necessária para sobrescrever os dados corrompidos em `ada1`.

    # zpool scrub healer
    # zpool status healer
      pool: healer
     state: ONLINE
    status: One or more devices has experienced an unrecoverable error.  An
                attempt was made to correct the error.  Applications are unaffected.
    action: Determine if the device needs to be replaced, and clear the errors
                using 'zpool clear' or replace the device with 'zpool replace'.
       see: http://illumos.org/msg/ZFS-8000-4J
      scan: scrub in progress since Mon Dec 10 12:23:30 2012
            10.4M scanned out of 67.0M at 267K/s, 0h3m to go
            9.63M repaired, 15.56% done
    config:

        NAME        STATE     READ WRITE CKSUM
        healer      ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
           ada0     ONLINE       0     0     0
           ada1     ONLINE       0     0   627  (repairing)

    errors: No known data errors

A operação scrub lê os dados do `ada0` e reescreve todos os dados com um checksum incorreto no `ada1`. Isso é indicado pela saída `(repairing)` do `zpool status`. Após a conclusão da operação, o status do conjunto é alterado para:

    # zpool status healer
      pool: healer
     state: ONLINE
    status: One or more devices has experienced an unrecoverable error.  An
            attempt was made to correct the error.  Applications are unaffected.
    action: Determine if the device needs to be replaced, and clear the errors
                 using 'zpool clear' or replace the device with 'zpool replace'.
       see: http://illumos.org/msg/ZFS-8000-4J
      scan: scrub repaired 66.5M in 0h2m with 0 errors on Mon Dec 10 12:26:25 2012
    config:

        NAME        STATE     READ WRITE CKSUM
        healer      ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
           ada0     ONLINE       0     0     0
           ada1     ONLINE       0     0 2.72K

    errors: No known data errors

Após a conclusão da operação scrub e todos os dados terem sido sincronizados de `ada0` para `ada1`, as mensagens de erro podem ser ??? do status do pool executando `zpool clear`.

    # zpool clear healer
    # zpool status healer
      pool: healer
     state: ONLINE
      scan: scrub repaired 66.5M in 0h2m with 0 errors on Mon Dec 10 12:26:25 2012
    config:

        NAME        STATE     READ WRITE CKSUM
        healer      ONLINE       0     0     0
          mirror-0  ONLINE       0     0     0
           ada0     ONLINE       0     0     0
           ada1     ONLINE       0     0     0

    errors: No known data errors

O pool está agora de volta a um estado totalmente funcional e todos os erros foram apagados.

### 19.3.9. Crescendo um Pool

O tamanho utilizável de um pool redundante é limitado pela capacidade do menor dispositivo em cada vdev. O menor dispositivo pode ser substituído por um dispositivo maior. Depois de concluir uma operação replace ou resilver, o pool pode crescer para usar a capacidade do Novo dispositivo. Por exemplo, considere um espelho de uma unidade de 1 TB e uma unidade de 2 TB. O espaço utilizável é de 1 TB. Quando a unidade de 1 TB é substituída por outra unidade de 2 TB, o processo de resilverização copia os dados existentes para a nova unidade. Como os dois dispositivos agora têm capacidade para 2 TB, o espaço disponível do espelho pode ser aumentado para 2 TB.

A expansão é acionada usando o `zpool online -e` em cada dispositivo. Após a expansão de todos os dispositivos, o espaço adicional fica disponível para o pool.

### 19.3.10. Importando e exportando pools

Os pools são exportados antes de serem movidos para outro sistema. Todos os conjuntos de dados são desmontados e cada dispositivo é marcado como exportado, mas ainda estarão bloqueados, para que não possam ser usados por outros subsistemas de disco. Isso permite que pools sejam importados em outras máquinas, outros sistemas operacionais que suportem ZFS , e até mesmo arquiteturas de hardware diferentes (com algumas advertências, veja zpool(8)). Quando um conjunto de dados tem arquivos abertos, o `zpool export -f` pode ser usado para forçar a exportação de um pool. Use isso com cautela. Os conjuntos de dados são forçosamente desmontados, resultando potencialmente em um comportamento inesperado dos aplicativos que tinham arquivos abertos nesses conjuntos de dados.

Exportar um pool que não está em uso:

    # zpool export mypool

Importar um pool automaticamente monta os conjuntos de dados. Este pode não ser o comportamento desejado e pode ser evitado com `zpool import -N`. O `zpool import -o` define propriedades temporárias apenas para esta importação. O `zpool import altroot=` permite importar um pool com um ponto base de montagem em vez da raiz do sistema de arquivos. Se o pool foi usado pela última vez em um sistema diferente e não foi exportado corretamente, uma importação pode ter que ser forçada com `zpool import -f`. O `zpool import -a` importa todos os pools que não parecem estar em uso por outro sistema.

Listar todos os pools disponíveis para importação:

    # zpool import
       pool: mypool
         id: 9930174748043525076
      state: ONLINE
     action: The pool can be imported using its name or numeric identifier.
     config:

            mypool      ONLINE
              ada2p3    ONLINE

Importe o pool com um diretório raiz alternativo:

    # zpool import -o altroot=/mnt mypool
    # zfs list
    zfs list
    NAME                 USED  AVAIL  REFER  MOUNTPOINT
    mypool               110K  47.0G    31K  /mnt/mypool

### 19.3.11. Atualizando um pool de armazenamento

Após a atualização do FreeBSD, ou se um pool foi importado de um sistema usando uma versão mais antiga do ZFS, o pool pode ser atualizado manualmente para a versão mais recente do ZFS para suportar as funcionalidades mais recentes. Considere se o pool pode precisar ser importado em um sistema antigo antes de atualizar. A atualização é um processo unidirecional. Os pools mais antigos podem ser atualizados, mas os pools com funcionalidades mais recentes não podem ser desatualizados.

Atualize um pool v28 para suportar `Feature Flags`:

    # zpool status
      pool: mypool
     state: ONLINE
    status: The pool is formatted using a legacy on-disk format.  The pool can
            still be used, but some features are unavailable.
    action: Upgrade the pool using 'zpool upgrade'.  Once this is done, the
            pool will no longer be accessible on software that does not support feat
            flags.
      scan: none requested
    config:

            NAME        STATE     READ WRITE CKSUM
            mypool      ONLINE       0     0     0
              mirror-0  ONLINE       0     0     0
    	    ada0    ONLINE       0     0     0
    	    ada1    ONLINE       0     0     0

    errors: No known data errors
    # zpool upgrade
    This system supports ZFS pool feature flags.

    The following pools are formatted with legacy version numbers and can
    be upgraded to use feature flags.  After being upgraded, these pools
    will no longer be accessible by software that does not support feature
    flags.

    VER  POOL
    ---  ------------
    28   mypool

    Use 'zpool upgrade -v' for a list of available legacy versions.
    Every feature flags pool has all supported features enabled.
    # zpool upgrade mypool
    This system supports ZFS pool feature flags.

    Successfully upgraded 'mypool' from version 28 to feature flags.
    Enabled the following features on 'mypool':
      async_destroy
      empty_bpobj
      lz4_compress
      multi_vdev_crash_dump

Os recursos mais recentes do ZFS não estarão disponíveis até que o `zpool upgrade` seja concluído. O `zpool upgrade -v` pode ser usado para ver quais os novos recursos que serão fornecidos pela atualização, bem como quais recursos já são suportados.

Atualize um pool para suportar feature flags adicionais:

    # zpool status
      pool: mypool
     state: ONLINE
    status: Some supported features are not enabled on the pool. The pool can
            still be used, but some features are unavailable.
    action: Enable all features using 'zpool upgrade'. Once this is done,
            the pool may no longer be accessible by software that does not support
            the features. See zpool-features(7) for details.
      scan: none requested
    config:

            NAME        STATE     READ WRITE CKSUM
            mypool      ONLINE       0     0     0
              mirror-0  ONLINE       0     0     0
    	    ada0    ONLINE       0     0     0
    	    ada1    ONLINE       0     0     0

    errors: No known data errors
    # zpool upgrade
    This system supports ZFS pool feature flags.

    All pools are formatted using feature flags.

    Some supported features are not enabled on the following pools. Once a
    feature is enabled the pool may become incompatible with software
    that does not support the feature. See zpool-features(7) for details.

    POOL  FEATURE
    ---------------
    zstore
          multi_vdev_crash_dump
          spacemap_histogram
          enabled_txg
          hole_birth
          extensible_dataset
          bookmarks
          filesystem_limits
    # zpool upgrade mypool
    This system supports ZFS pool feature flags.

    Enabled the following features on 'mypool':
      spacemap_histogram
      enabled_txg
      hole_birth
      extensible_dataset
      bookmarks
      filesystem_limits

### Atenção:

O boot code em sistemas que inicializam a partir de um pool deve ser atualizado para suportar a nova versão do pool. Use `gpart bootcode` na partição que contém o boot code. Existem dois tipos de bootcode disponíveis, dependendo da forma como o sistema inicializa: GPT (a opção mais comum) e EFI (para sistemas mais modernos).

Para inicialização legada usando o GPT, use o seguinte comando:

    # gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot -i 1 ada1

Para sistemas que usam o EFI para inicializar, execute o seguinte comando:

    # gpart bootcode -p /boot/boot1.efifat -i 1 ada1

Aplique o bootcode a todos os discos inicializáveis no pool. Veja gpart(8) para obter maiores informações.

### 19.3.12. Exibindo o histórico gravado do pool

Comandos que modificam o pool são registrados. As ações registradas incluem a criação de conjuntos de dados, a alteração de propriedades ou a substituição de um disco. Esse histórico é útil para revisar como um pool foi criado e qual usuário executou uma ação específica e quando. O histórico não é mantido em um arquivo de log, mas faz parte do próprio pool. O comando para revisar este histórico é apropriadamente chamado de `zpool history`:

    # zpool history
    History for 'tank':
    2013-02-26.23:02:35 zpool create tank mirror /dev/ada0 /dev/ada1
    2013-02-27.18:50:58 zfs set atime=off tank
    2013-02-27.18:51:09 zfs set checksum=fletcher4 tank
    2013-02-27.18:51:18 zfs create tank/backup

A saída mostra os comandos `zpool` e `zfs` que foram executados no pool juntamente com um registro de data e hora. Somente comandos que alteram o pool de alguma forma são registrados. Comandos como `zfs list` não estão incluídos. Quando nenhum nome de pool é especificado, é exibido o histórico de todos os pools.

O `zpool history` pode mostrar ainda mais informações quando as opções `-i` ou `-l` são fornecidas. A opção `-i` exibe eventos iniciados pelo usuário, bem como eventos do ZFS registrados internamente.

    # zpool history -i
    History for 'tank':
    2013-02-26.23:02:35 [internal pool create txg:5] pool spa 28; zfs spa 28; zpl 5;uts  9.1-RELEASE 901000 amd64
    2013-02-27.18:50:53 [internal property set txg:50] atime=0 dataset = 21
    2013-02-27.18:50:58 zfs set atime=off tank
    2013-02-27.18:51:04 [internal property set txg:53] checksum=7 dataset = 21
    2013-02-27.18:51:09 zfs set checksum=fletcher4 tank
    2013-02-27.18:51:13 [internal create txg:55] dataset = 39
    2013-02-27.18:51:18 zfs create tank/backup

Mais detalhes podem ser mostrados adicionando a opção `-l`. Os registros de histórico são mostrados em um formato longo, incluindo informações como o nome do usuário que emitiu o comando e o nome do host no qual a alteração foi feita.

    # zpool history -l
    History for 'tank':
    2013-02-26.23:02:35 zpool create tank mirror /dev/ada0 /dev/ada1 [user 0 (root) on :global]
    2013-02-27.18:50:58 zfs set atime=off tank [user 0 (root) on myzfsbox:global]
    2013-02-27.18:51:09 zfs set checksum=fletcher4 tank [user 0 (root) on myzfsbox:global]
    2013-02-27.18:51:18 zfs create tank/backup [user 0 (root) on myzfsbox:global]

A saída mostra que o usuário `root` criou o pool espelhado com os discos `/dev/ada0` e `/dev/ada1`. O nome do host `myzfsbox` também é mostrado nos comandos após a criação do pool. A exibição do nome do host se torna importante quando o pool é exportado de um sistema e importado para outro. Os comandos que são emitidos no outro sistema podem claramente ser distinguidos pelo nome do host que é registrado para cada comando.

Ambas as opções para o `zpool history` podem ser combinadas para fornecer as informações mais detalhadas possíveis para qualquer pool. O histórico do pool fornece informações valiosas ao rastrear as ações que foram executadas ou quando é necessária uma saída mais detalhada para a depuração.

### 19.3.13. Monitoramento de Desempenho

Um sistema de monitoramento integrado pode exibir estatísticas de I/O do pool em tempo real. Ele mostra a quantidade de espaço livre e usado no pool, quantas operações de leitura e gravação estão sendo executadas por segundo e quanto de largura de banda de I/O está sendo utilizada no momento. Por padrão, todos os pools no sistema são monitorados e exibidos. Um nome de pool pode ser fornecido para limitar o monitoramento apenas a esse pool. Um exemplo básico:

    # zpool iostat
                   capacity     operations    bandwidth
    pool        alloc   free   read  write   read  write
    ----------  -----  -----  -----  -----  -----  -----
    data         288G  1.53T      2     11  11.3K  57.1K

Para monitorar continuamente a atividade de I/O, um número pode ser especificado como o último parâmetro, indicando um intervalo em segundos para aguardar entre as atualizações. A próxima linha de estatística é impressa após cada intervalo. PressioneCtrl+C para interromper este monitoramento contínuo. Como alternativa, forneça um segundo número na linha de comando após o intervalo para especificar o número total de estatísticas a serem exibidas.

Estatísticas mais detalhadas de I/O podem ser exibidas com a opção `-v`. Cada dispositivo no pool é mostrado com uma linha de estatísticas. Isso é útil para ver quantas operações de leitura e gravação estão sendo executadas em cada dispositivo e pode ajudar a determinar se algum dispositivo individual está reduzindo a velocidade do pool. Este exemplo mostra um pool espelhado com dois dispositivos:

    # zpool iostat -v
                                capacity     operations    bandwidth
    pool                     alloc   free   read  write   read  write
    -----------------------  -----  -----  -----  -----  -----  -----
    data                      288G  1.53T      2     12  9.23K  61.5K
      mirror                  288G  1.53T      2     12  9.23K  61.5K
        ada1                     -      -      0      4  5.61K  61.7K
        ada2                     -      -      1      4  5.04K  61.7K
    -----------------------  -----  -----  -----  -----  -----  -----

### 19.3.14. Dividindo um pool de armazenamento

Um pool que consiste em um ou mais vdevs espelhados pode ser dividido em dois conjuntos. A menos que seja especificado de outra forma, o último membro de cada espelho é desanexado e usado para criar um novo pool contendo os mesmos dados. A operação deve primeiro ser tentada com `-n`. Os detalhes da operação proposta são exibidos sem que sejam realmente executados. Isso ajuda a confirmar que a operação fará o que o usuário pretende.

Anterior | Acima | Próxima
19.2. Guia de Início Rápido | Principal | 19.4. Administração do `zfs`

All FreeBSD documents are available for download at https://download.freebsd.org/ftp/doc/

Questions that are not answered by the documentation may be sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.